:  Настроен план обмен «По организации».  Головной узел развернут на ОС 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 тыс. строк. Как замер включить?

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

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

насчет настроек PostgreSQl - столько везде пишут всего.. и не пойми где истина. Понятно памяти мало.. Понятно RAID не настроен - кстати PostgreSQL очень зависима от производительности винта.. так как все операции кэшируются на винт.

Если кто поделится опитамальными настройками Postgresql... ОЗУ 3ГБайт. Сервак +СУБД вместе. Пользователей 5-6.

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

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

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

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

(8) man iotop

max_connections = 100    
shared_buffers = 1024MB
temp_buffers = 24MB
work_mem = 64MB
maintenance_work_mem = 128MB
max_fsm_pages = 1024000        
max_fsm_relations = 10000    
wal_buffers = 64kB            
checkpoint_timeout = 10min        
checkpoint_warning = 60s        
enable_nestloop = on
log_destination = 'stderr'        
logging_collector = on            
log_directory = 'pg_log'        
log_truncate_on_rotation = on    
log_rotation_age = 1d            
log_rotation_size = 0            
client_min_messages = warning    
log_min_messages = warning        
log_line_prefix = '%t dbname:%d '    
track_activities = off        
track_counts = on        
update_process_title = on    
log_parser_stats = off            
log_planner_stats = off            
log_executor_stats = off        
log_statement_stats = off        
autovacuum = off            
deadlock_timeout = 2s        
max_locks_per_transaction = 200
default_with_oids = on            
escape_string_warning = off

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

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

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

еще проверь размер файла pgstat.stat в каталоге global, что с ним может быть не так здесь:
http://www.sql.ru/forum/actualthread.aspx?tid=918563

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

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

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

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

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

(17)Тут посмотрите, не так давно обсуждалсь - v8: Производительность сервера 1с

(18) аналогично, 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 пользователей. Но так как обед. Ничего там не происходит.

listen_addresses = '127.0.0.1'        
max_connections = 100            
shared_buffers = 512MB            
temp_buffers = 20MB            
work_mem = 256MB            
maintenance_work_mem = 1024MB        
synchronous_commit = off        
full_page_writes = off            
wal_buffers = 2048kB            
checkpoint_segments = 12        
checkpoint_timeout = 15min        
random_page_cost = 1.5            
cpu_tuple_cost = 0.001            
cpu_index_tuple_cost = 0.0005        
cpu_operator_cost = 0.00025        
effective_cache_size = 16384MB
log_destination = 'stderr'        
logging_collector = on            
log_directory = 'pg_log'        
log_filename = '%d-%m-%Y.log'        
log_truncate_on_rotation = on        
log_rotation_age = 1d            
log_rotation_size = 0            
autovacuum_naptime = 5min        
datestyle = 'iso, dmy'
lc_messages = 'ru_RU.UTF-8'            
lc_monetary = 'ru_RU.UTF-8'            
lc_numeric = 'ru_RU.UTF-8'            
lc_time = 'ru_RU.UTF-8'                
default_text_search_config = 'pg_catalog.russian'
deadlock_timeout = 2s
max_locks_per_transaction = 250        
default_with_oids = on
escape_string_warning = off

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

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

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

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

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

listen_addresses = '*'            
max_connections = 100            
shared_buffers = 256MB
temp_buffers = 16MB
work_mem = 64MB
maintenance_work_mem = 256MB
fsync = off
wal_buffers = 512kB    
checkpoint_segments = 12
checkpoint_timeout = 15min
effective_cache_size = 512MB
log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
#autovacuum = on
autovacuum_naptime = 5min
datestyle = 'iso, dmy'
lc_messages = 'ru_RU.UTF-8'            
lc_monetary = 'ru_RU.UTF-8'            
lc_time = 'ru_RU.UTF-8'                
default_text_search_config = 'pg_catalog.russian'
default_with_oids = on
escape_string_warning = off

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

вот пример лога обмен. размер архива 120 кБайт.

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

(31) неважно, у меня счас тоже отключен когда конфы обновляю (через консоль ставлю блок на выполнение регл.заданий), просто тогда будет возможность загрузить по максимум сервер чтоб сделал обмен

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

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

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

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

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

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

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

тмз *scratch*

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

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

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

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

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

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

(44) 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

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

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

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

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

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

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

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

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

listen_addresses = '*'            
max_connections = 100            
shared_buffers = 256MB
temp_buffers = 16MB
work_mem = 64MB
maintenance_work_mem = 256MB
fsync = off
wal_buffers = 512kB    
checkpoint_segments = 12
checkpoint_timeout = 15min
effective_cache_size = 512MB
log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
autovacuum_naptime = 5min
datestyle = 'iso, dmy'
lc_messages = 'ru_RU.UTF-8'            
lc_monetary = 'ru_RU.UTF-8'            
lc_time = 'ru_RU.UTF-8'                
default_text_search_config = 'pg_catalog.russian'
default_with_oids = on
escape_string_warning = off

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

(57)Вот тут
http://phpclub.ru/detail/store/pdf/postgresql-performance.pdf
рекомендуется
25-50% от доступной памяти. Это, естественно, в случае загрузки железа только постгрёй. Т.е. в твоем случае можно попробовать увеличить до 1 ГБ.

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

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

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

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

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

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

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

Или так

SELECT pg_size_pretty(pg_database_size('testdb'));

SELECT
   pg_tables.schemaname,
   pg_tables.tablename,
   pg_size_pretty(pg_total_relation_size(((pg_tables.schemaname::text || '.'::text) || pg_tables.tablename::text)::regclass)) AS totalsize,
   pg_size_pretty(pg_relation_size(((pg_tables.schemaname::text || '.'::text) || pg_tables.tablename::text)::regclass)) AS relsize
 FROM pg_tables
WHERE pg_tables.schemaname <> 'information_schema'::name
ORDER BY pg_total_relation_size(((pg_tables.schemaname::text || '.'::text) || pg_tables.tablename::text)::regclass) DESC;

Взято  отсюда - http://www.sql.ru/forum/actualthread.aspx?bid=7&tid=743577&pg=2&hl=pg_total_relation_size

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

(49)  сделал переиндексацию - полёт такой же "тупой".

смотрел процессы от 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

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

После работы поиграюсь с конфигом.. посмотрим что получится.

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

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

(70)Ну тогда запустите все в режиме отладки, и клиента, на котором выполняется обмен, и технологический журнал на сервере и постгрес в режиме отладки можно тоже запустить.
Чтобы выяснить, чем реально заняты эти процессы в течение 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 вроде не надо такой большой, это ж как раз отвечает за накопление и сброс на винт транзакций.
и для теста остановите автовакуум еще

а точно нету файла из (15)?Щ_Щ из-его размера очень-большие тормоза могут быть, проверено:)

(72) А это поудалять надо.
v8: PostgreSQL 8.4.4 autovacuum found orphan temp table

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

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

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