Долго идет обмен данными 1С+PostgreSQL #605392

:  Настроен план обмен «По организации».  Головной узел развернут на ОС Fedora 7 + СУБД PostgreSQL 8.4 + сервер 1С 8.2.14.540, количество пользователей в пределах 5.  Параметры сервера: Fujitsu-Siemens PRIMERGY RX 600S3 , Intel® Xeon® MP, 4 Г ОЗУ, 3 скоростных жестких диска, без RAID. Подчиненный узел РИБ: платформа 1С 8.2.14.540 на Windows Home, база в файловом варианте, 1 пользователь. Обмен происходит через FTP, и резервно иногда вручную через рабочие папки. Обмен в подчиненном узле происходит довольно быстро: архивы с данными размером в 1-2 мегабайта в пределах 10 минут. А на стороне главного узла обмен идет долго. Архив загружается 300 кБайт – час где-то.  И задержка именно на этапе внесения данных в базу, проблем с копированием файла с FTP нет. Тестирование и исправление базы делал.  Выгрузка базы примерно размером в 300 Мбайт. В развернутом состоянии 3ГБайта. Так как обмены у нас производятся минимум раз в сутки и обычно в течении рабочего дня, то это очень неудобно и неэффективно.

Если в ручную обмен делать (не рег заданием) - сколько идёт? замер производительности включить может?

Регламентно  - это по расписанию автоматически? Ну тогда у меня вручную. Через FTP. Делал через папки - эффект тот же. Хотел бы добавить инфу по базу: в регстре бухгалтерии около 1 млн 400 тыс. строк. Как замер включить?

Оптимизируйте конфиг постгри, однозначно он захлебывается из-за нерациональных настроек.

+ паралельно включить iotop -o -a на линуксе и смотреть что грузит винт

насчет настроек PostgreSQl - столько везде пишут всего.. и не пойми где истина. Понятно памяти мало.. Понятно RAID не настроен - кстати PostgreSQL очень зависима от производительности винта.. так как все операции кэшируются на винт. Если кто поделится опитамальными настройками Postgresql... ОЗУ 3ГБайт. Сервак +СУБД вместе. Пользователей 5-6.

iotop -o -a  а что за параметры такие? через --help смотрел  нету.

yum install iotop :) Показывает И/О обращение к диску и процес что грузит винт, особенно надо такой командой смотреть если в команде top значение wa > 30-50%

Ну установить я то смог :) я же пишу что в --help нет параметров -о и -а

конфиг файл счас сокращу от дефаулт значений и сюда сброшу, может кто и проверит что не так еще :)

man iotop

А у тебя какая версия Постгри? И оператичной памяти скольк?

+ всего 30 пользователей, 1 база УТП + база бух.~ 7 шт.(риб между бух.базами с обменом по организации). 8гб ОЗУ, постгрес 64х, 1С-ка 32х. postgres 8.4.3 пока еще.

+ данную настройку собирал по крошкам из нета, хз все ли здесь правильно :) но сейчас работает без тормозов. автовакуум выключен, так как настроен в кроне ночью для всех баз. Иначе днем автовакуум подгружал винт очень, а винт медленный стоит.

еще проверь размер файла pgstat.stat в каталоге global, что с ним может быть не так здесь:

Знаешь у меня параметр wa в команде TOP 2,5 процентов  - я сейчас загрую инфобазу в тестовую. То есть нагрузка большая.. А вот id постояно за 90.

Мне бы еще в структуре конфига разобраться... Кстати не  нашел я pgstat.stat в папке global

fsync, наверное, включен...а без зеркала и батарейки или модуля защиты от сбоев выключать нельзя.

id большое это хорошо :) id = idel=простой

2.5% - это практически ничего. а %us и %sys что показывают?

Тут посмотрите, не так давно обсуждалсь -

аналогично, fsync не выключал, страшновато его трогать top - 10:38:38 up 8 days, 16:56,  1 user,  load average: 0.10, 0.20, 0.23 Tasks: 141 total,   2 running, 139 sleeping,   0 stopped,   0 zombie Cpu0  :  1.3%us,  0.3%sy,  0.0%ni, 96.7%id,  1.3%wa,  0.0%hi,  0.3%si,  0.0%st Cpu1  :  2.3%us,  1.0%sy,  0.0%ni, 90.8%id,  5.9%wa,  0.0%hi,  0.0%si,  0.0%st онлайн сейчас: 22 пользователя

Делал сейчас обмен. Архив 23кБайт  - 3 с половиной минуты. top - 13:26:50 up 9 days, 21:09,  1 user,  load average: 0.02, 0.28, 0.62 Tasks: 236 total,   1 running, 235 sleeping,   0 stopped,   0 zombie Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem:   3368220k total,  3231520k used,   136700k free,    18004k buffers Swap:  9414080k total,       96k used,  9413984k free,  2785532k cached В базе сейчас 6 пользователей. Но так как обед. Ничего там не происходит.

обмен вручную с ГУИ, или через сервер? от этого очень зависит скорость, с гуи (интерактивный) всегда дольше в 2-5 раз.

25 Извини, но не понял что значит "обмен вручную с ГУИ"

effective_cache_size = 16384MB - это как? У вас физической памяти 4 гига всего. Рекомедуют от четверти до половины всей памяти этот параметр устанавливать. Ну и в качестве эксперимента fsync=off попробуйте(раз все равно обед).

извиняюсь......... это же конфиг тестового... Сейчас выложу рабочий

в окне настроек обмена, для обмена есть закладка автообмен, и внизу в тч настройка обмена. + на закладке дополнительно "птичка" под полн.правами.

У меня автоматический обмен не настроен...

вот пример лога обмен. размер архива 120 кБайт. [05.04.2012 21:29:43] [Администратор 1С] Начало распаковки файла обмена данными C:Documents and SettingsVladimirGLocal SettingsTempПоОрганизацииЗаозерное - Кокшетау (использовать)Message_002_001.zip [05.04.2012 21:29:43] [Администратор 1С] Окончание распаковки файла обмена данными C:Documents and SettingsVladimirGLocal SettingsTempПоОрганизацииЗаозерное - Кокшетау (использовать)Message_002_001.zip. Распакованные данные помещены в файл C:Documents and SettingsVladimirGLocal SettingsTempMessage_002_001.xml [05.04.2012 21:29:43] [Администратор 1С] Начало чтения изменений из файла обмена C:Documents and SettingsVladimirGLocal SettingsTempMessage_002_001.xml [05.04.2012 22:04:50] [Администратор 1С] Окончание чтения изменений из файла обмена C:Documents and SettingsVladimirGLocal SettingsTempMessage_002_001.xml [05.04.2012 22:04:50] [Администратор 1С] Чтение данных из файла обмена успешно завершено.

неважно, у меня счас тоже отключен когда конфы обновляю (через консоль ставлю блок на выполнение регл.заданий), просто тогда будет возможность загрузить по максимум сервер чтоб сделал обмен так может данных действительно много в 120кб архива. Попробуй в базе источнике посмотреть чего так много грузит, через операции-план обмена - по организации + вверху иконка" монитора - зарегистр.изменения

Кстати у меня стоит блок на выполнение регл. заданий. Через консоль администрирования смотрю.

Сколько времени учет в центр.иб ведется? Может пора уже пересчет регистров сделать...

с 2007 года. Пересчет регистров - это?

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

Обычно с филиале документы: Поступление ТМЗ, Перемещение ТМЗ и Списание ТМЗ. Ну номеклатуру забивают. Такоо типа доки обычно в архиве. В журнале регистрации смотрел.

если блок на выполнение регл. заданий стоит с 2007 года, то после пересчета счас все будет летать :)

тмз *scratch*

кон мая 2010.... кстати знаешь я только утром об этом думал. Всзял на тестовой сделал. Отчеты стали конечно быстрей выводится. Загружал на рабочей в обед архив обмена 25 к Байт  - 3,5 минуты. Правда в базе 5 пользователей обитали без дела. На тестовой этот же архив - 2,5 минуты.. Тоже много.. и не понятно прирост за счет чего - может за счет того что я в базе один был тестовой

Кстати управление итогами влияет только на производительность? Опасаться ничего не стоит после проведения этой процедуры?

все норм, не полезет, но бекап я б сделал :)

Рассчитал итоги. Не помогло. 90 кБайт архив в клиент-серверном варианте грузится 18 мин. В файловом  - 35 сек. Может переиндексацию базы средствами PostgreSQL сделать? Проблема в сервере точно... Только как делать не знаю точно..

Размер базы-то у тебя какой?

В файловом варианте - до 5ГБайт. Размер базы в СУБД - около 8-9ГБайт.

reindexdb -U postgres dbname в командной строке. Впрочем, при тестировании и исправлении, реиндексация делает то же самое. Так сервер чем занят все эти 18 минут?

47. Да особо не загружен получается сервер. Только вот оперативка почти на 100 процентов используется всегда. примерная такая картина всегда памятью Mem:   3368220k total,  3231520k used,   136700k free,    18004k buffers Swap:  9414080k total,       96k used,  9413984k free,  2785532k cached

Это понятно, при 4ГБ по другому и не бывает. Вполне вероятно, что алгоритм приема в файловом и клиент-серверном вариантах работает как-то по разному. То, что быстро работает в файловом, по каким-то причинам тормозит в клиент-серверном, причем именно с постгрес. Попробуйте, во время приема архива, на сервере выполнить watch "ps ax | grep postgres", чтобы посмотреть чем занят постгрес, каждые 2 секунды будет обновление. А в pgstartup.log по поводу checkpoint_segments ничего не пишется в массовом порядке?

#47 reindexdb -h localhost -U postgres -d testbase    - получилось такой командой. это пока на тестовой базе. тяжело проверять эти обмены. надо базу грзуить постоянно заново.

извините за глупый наверное вопрос - как вы делаете ссылки на сообщение?

не получилось :) просто неудобно писать.

Я пробовал загружать вручную сообщение данными обмена через операции - плны обмена. Так я понимаю это делается напрямую. Но по времени получилось так же долго.

в pgstartup.log по поводу checkpoint_segments  никаких данных нет...

А кто что по конфигу скажет:

может effective_cache_size = 512MB  маловато..?

Вот тут рекомендуется 25-50% от доступной памяти. Это, естественно, в случае загрузки железа только постгрёй. Т.е. в твоем случае можно попробовать увеличить до 1 ГБ.

номер сообщения в скобки возьмите, будет ссылка. 1024 поставьте, ну и shared_buffers 512, может получше будет.

Хорошоая ссылка, кратко и внятно.

Вообще, насколько я помню, в статье по ссылке из моего далеко не всё. Я находил статью, где всё подано более подробно. Вот только статья эта дома, а ни автора, ни точного названия не помню. Навскидку меня смущает слишком большой checkpoint_timeout, но именно навскидку, утверждать не берусь.

Вот еще ссылка, ИМХО, более подробная, чем первая и цитата оттуда "maintenance_work_mem ... Чтобы операции выполнялись максимально быстро, нужно устанавливать этот параметр тем выше, чем больше размер таблиц в вашей базе данных. Неплохо бы устанавливать его значение от 50 до 75% размера вашей самой большой таблицы или индекса".

"checkpoint_segments: определяет количество сегментов (каждый по 16 МБ) лога транзакций между контрольными точками. Этот параметр не имеет особого значения для базы данных, предназначенной преимущественно для чтения, но для баз данных со множеством транзакций увеличение этого параметра может оказаться жизненно необходимым. В зависимости от объема данных установите этот параметр в диапазоне от 12 до 256 сегментов" Как видишь, у тебя стоит минимальное значение - 12, что для БД с большим количеством транзакций некузяво. Попробуй поэтапно поднимать.

Я был на этих ресурсах уже. effective_cache_size для начала увеличу. Насчет maintenance_work_mem ..как узнать то размер самой большой таблицы...

Посмотреть список таблиц в постгре или непосредственно размер файлов через любой файловый манагер.

Взято  отсюда - А по хорошему, поставить на гораздо более новый компьютер с большим количеством памяти (16-32 ГБ) самые последние версии всего( ОС, PostgreSQL, 1С) и уже на нем разбираться. База около 9 ГБ, еще не совсем большая, но уже и немаленькая...

сделал переиндексацию - полёт такой же "тупой". смотрел процессы от postgres вот выхлоп... 23615 ?        S      0:00 /usr/bin/postmaster -p 5432 -D /postgres/data 23619 ?        Ss     0:00 postgres: logger process 23625 ?        Ss     0:09 postgres: writer process 23626 ?        Ss     0:00 postgres: wal writer process 23627 ?        Ss     0:05 postgres: autovacuum launcher process 23628 ?        Ss     0:20 postgres: stats collector process 26914 ?        Rs     3:04 postgres: postgres test1 127.0.0.1(48820) INSERT 26927 ?        Ss     0:00 postgres: postgres test1 127.0.0.1(48830) idle 26942 pts/0    S+     0:00 grep postgres

Ну тут не все так просто как обычно - административные припоны... ключ серверный на 32 разрядную ОС расчитан.. В свое время админ до меня не продумал...   После работы поиграюсь с конфигом.. посмотрим что получится.

Если это  - postgres test1 127.0.0.1(48820) INSERT - длится на протяжении всего процесса обмена, то оно и занимает большую часть времени, то есть, собственно, INSERT столько и выполняется. А если INSERT занимает 3 минуты всего, значит что-то другое еще...

изменил значение effective_cache_size до 1024 МБайт - обмен длится ровно столько же сколько и раньше 17мин20сек. Перегрузил сервер - сделал обмен - ОЗУ свободной было достаточно - результат тот же 17 мин 20 сек. Изменил значение checkpoint_segments с 12 на 34 - не помогло. изменил checkpoint_timeout c 15 до 5 мин - не помогло... Уж и не знаю что и думать...........................

Ну тогда запустите все в режиме отладки, и клиента, на котором выполняется обмен, и технологический журнал на сервере и постгрес в режиме отладки можно тоже запустить. Чтобы выяснить, чем реально заняты эти процессы в течение 18 минут.

в pg_log заметил что пишется такое.. раньше не было: LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt21" in database "test1" LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt22" in database "test1" LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt24" in database "test1" LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt25" in database "test1" LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt26" in database "test1" LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt27" in database "test1" LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt32" in database "test1" LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt34" in database "test1" LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt35" in database "test1" LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt41" in database "test1" LOG:  autovacuum: found orphan temp table "pg_temp_3"."tt46" in database "test1"

wal_buffers = 512kB вроде не надо такой большой, это ж как раз отвечает за накопление и сброс на винт транзакций. и для теста остановите автовакуум еще а точно нету файла из ?Щ_Щ из-его размера очень-большие тормоза могут быть, проверено:)

А это поудалять надо.

Только желательно, чтобы пользователей не было в базе в это время.

Поставил PostgreSQL 64  на выделеный зеркало SSD, машина виндовая, мощный пк, обмены УПП летают, только один рекомендованый параметр в ПГ подправил, на ИТС рекамендовано было и все.

нашёл файл. Правда он находится в папке data/pg_stat_tmp Правда размер небольшой 1,5МБайт...