1С Сервер 8.2 + Debian 7 + PostgreSQL 9.1 = медленно работает #691030

Привет всем. Если у кого есть опыт настройки 1С Сервера под linux - просьба помочь. Проблема вкратце (подробности ниже): новая установка сервера под debian 7 wheezy с постгресом; обычный документ (ничего сверхестественного) проводится 14 секунд (1 пользователь в системе); судя по диагностическим данным, в железо не упирается. В понедельник попытаюсь обратиться в техподдержку 1С (сервер лицензионный), но может сможете что-нибудь порекомендовать заранее? Подробности. Версии: * два виртуализированных сервера: под СУБД - debian 7 wheezy x64, под 1С - debian 7 wheezy x86; * 1С Сервер и клиент: 8.2.19.76 * postgresql: 9.1.2-1.1C * конф: ВДГБ НКО 4.4 (в основе БП 2.0) * лицензия на сервер: электронная, пока не активирована на период тестирования Наблюдения (тестируется проведение документа "Поступление на расчётный счёт"): * соседний процесс rphost падает в segfault в libc при периодическом запуске на нём регламентных операций 1С * бОльшую часть времени во время проведения клиентский процесс постгреса висит в "idle in transaction" * процессы СУБД и 1С-сервера не вызывают высокое потребление CPU или CPU I/O wait, не упираются в память * tcp-коммуникация между серверами внутри виртуализированной сети проверена iperf - в норме, 2 гигабита, без потерь и jitter-а * технологический журнал (включено EXCP, EXCPCNTX, PROC, ADMIN, MEM, LEAKS, QERR, TLOCK, TDEADLOCK, TTIMEOUT): ничего особенного, записи TLOCK во время проведения * замер производительности отладчиком показывает наибольшее потребление времени запросами (Выполнить и т.п.) * пробовал в постгресе включить лог autovacuum дольше 500 мс: во время проводок в логе ничего * пробовал в постгресе включить лог длительности всех запросов + логирование запросов дольше 20 мс: за ~14 секунд выполяется множество запросов, но большинство менее 1 мс, 2-4 по 1-2 мс и один select на ~30 мс; суммарно не более 500 мс * пробовал в постгресе логировать deadlock-и (deadlock_timeout = 500ms, log_lock_waits = on): в итоге ничего Пока грешу на работу самой платформы на debian 7 (на это ещё указывает падения rphost на регламентах, хотя может быть конфа виновата). Может стоит переставить на 6-ой? Что скажете?

что мешает приобрести продукты от MS и заниматься делами, а не сношением с операционной системой?

Наверно, дороговизна продуктов от ms для трудящихся?

Либо долго и муторно разбираться в конфигах PostgreSQL, либо поставить DB2 Express-C 10.1. IBM куда как проще, да и производительности хватает.

а где ее взять?

ответ принимается частично :-) но на данном этапе дополнительные затраты на MS не обоснованы, учитывая что 1С заявляет работу на указанном. Ну почти - заявляет на debian 6... Тем более для кого сношение, а для кого - норма, у нас windows-сервера в меньшинстве в инфраструктуре. вообще не кажется, что проблема в постгресе. Наслышан о проблеме блокировок (row vs. table locks), но тут: а) единственный пользователь проводит документ, чьи ему локи-то ждать; б) запросы вроде пролетают быстро, тормозит на уровне приложения. Потом попробую deadlock_timeout снизить и снова пологировать, возможно тут всё-таки идёт ожидание блокировок, но их много и все они менее 500 мс.

Если конфигурация на базе БП 2.0 - там нет проблем с табличными блокировками. Я ставлю на проблемы с выделением памяти и fsync. Но разбираться по фотографии с учетом виртуализации - нафиг, нафиг. Я слишком на Вы с постгресом для этого.

постгре, линух, вирутализация.... "9 граммов в сердце"....

Да лана вам у меня стоит сервак на Линуксе (ЦентОС) + Постгрес и все нормально пашет Все ремонадации как вчегда сводятся - купи самолет, на нем картошку лучше возить

2 круто, сенкс. а то я авеча искал - никак не мог найти, всюду вылазила только 10.5, а она на под типовыми валилась как последняя сволочь

2 да, я знаю, у многих Постгресс работает, начинаешь спрашивать как настраивал, оказывается что настраивал кто-то другой. Спрашиваешь - как мне настроить так, чтобы у меня было нормально - отвечают "Я не знаю, просто поставил и оно заработало".

>процесс rphost падает в segfault в libc при периодическом запуске на нём регламентных операций 1С Из личных наблюдений: при числе фоновых заданий 50-60 на один рабочий процесс, сервер приложений просто виснет(редко падает, это, кстати, в ошибках к версии платформы 8.2.19 указано. Правда они почему-то указали число 500, думается, что нолик просто приписали. Когда планируется исправить, неизвестно. Хорошо  видно при выполнении многопоточных тестов. Процессы postgres-а не завершаются, а висят именно в том состоянии, как вы указали. Приходится перезапускать службу postgres-а.

1Сники про 10.5 отмалчиваются как партизаны. Есть такая страница: Возьми в избранное - там всегда есть ссылки на совместимые дистрибутивы ПО.

ну много в и-нет рекомендаций , я сам настраивал вот еще хорошая книга есть

они вот тут как бы намекают ))

Ну да. Кстати, написано простым человеческим языком - "убийство сервера", "это бессмысленно". По ходу, развернутая памятка своим собственным программистам. Без виртуализации никак не получается? Хотя бы для того, чтобы выяснить, что же мешает.

Приобрели, развернули. Жалуются. Ну или занимаются тем самым, про что ты написал.

Вы пишете: "...соседний процесс rphost падает в segfault в libc при периодическом запуске на нём регламентных операций 1С" Это, похоже, ошибка самой платформы 8.2.19, ставьте 8.2.18.109, она вполне безглючная. Дебиан тут не при чем, на Centos и Ubuntu то же самое. Насчет платформы - я бы все же ставил на CentOS. Недавно вышел релиз 6.5, много полезных улучшений. Совершенно беспроблемно все работает. Настройка PostgreSQL на виртуалке - отдельное искусство. Буквально на днях было интересное обсуждение этого вопроса в рассылке PostgreSQL Performance, гуру много полезных вещей подсказали. Ну и в подобных статьях и на форумах тоже есть крупицы опыта.