Привет всем.

Если у кого есть опыт настройки 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-ой? Что скажете?

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

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

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

(3) а где ее взять?

(1) ответ принимается частично :-) но на данном этапе дополнительные затраты на MS не обоснованы, учитывая что 1С заявляет работу на указанном. Ну почти - заявляет на debian 6...

Тем более для кого сношение, а для кого - норма, у нас windows-сервера в меньшинстве в инфраструктуре.

(3) вообще не кажется, что проблема в постгресе. Наслышан о проблеме блокировок (row vs. table locks), но тут: а) единственный пользователь проводит документ, чьи ему локи-то ждать; б) запросы вроде пролетают быстро, тормозит на уровне приложения.

Потом попробую deadlock_timeout снизить и снова пологировать, возможно тут всё-таки идёт ожидание блокировок, но их много и все они менее 500 мс.

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

(4) https://www14.software.ibm.com/webapp/iwm/web/reg/pick.do?source=swg-db2expressc&S_TACT=109HF15W&lang=ru_RU

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

"9 граммов в сердце"....

Да лана вам

у меня стоит сервак на Линуксе (ЦентОС) + Постгрес и все нормально пашет

Все ремонадации как вчегда сводятся - купи самолет, на нем картошку лучше возить

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

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

(0)>процесс rphost падает в segfault в libc при периодическом запуске на нём регламентных операций 1С

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

(10) 1Сники про 10.5 отмалчиваются как партизаны. Есть такая страница: http://v8.1c.ru/requirements/
Возьми в избранное - там всегда есть ссылки на совместимые дистрибутивы ПО.

(11)  ну много в и-нет рекомендаций , я сам настраивал



вот еще хорошая книга есть
http://postgresql.leopard.in.ua

(12) они вот тут как бы намекают ))
http://v8.1c.ru/o7/201312opt/index.htm

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

(1)http://www.gilev.ru/forum/viewtopic.php?f=8&t=485
Приобрели, развернули. Жалуются. Ну или занимаются тем самым, про что ты написал.

(0) Вы пишете: "...соседний процесс rphost падает в segfault в libc при периодическом запуске на нём регламентных операций 1С"

Это, похоже, ошибка самой платформы 8.2.19, ставьте 8.2.18.109, она вполне безглючная. Дебиан тут не при чем, на Centos и Ubuntu то же самое.
Насчет платформы - я бы все же ставил на CentOS. Недавно вышел релиз 6.5, много полезных улучшений. Совершенно беспроблемно все работает.

Настройка PostgreSQL на виртуалке - отдельное искусство. Буквально на днях было интересное обсуждение этого вопроса в рассылке PostgreSQL Performance, гуру много полезных вещей подсказали.
http://postgresql.1045698.n5.nabble.com/Postgresql-in-a-Virtual-Machine-td5780207.html

Ну и в подобных статьях и на форумах тоже есть крупицы опыта.
http://arstechnica.com/civis/viewtopic.php?t=1167159

http://highperfpostgres.com/2013/09/tuning-disk-timeouts-virtual-machines/