Здравствуйте.
Вопрос про связку 1C8 + postgresql , поднятую на дебиане Lenny. Испытываем проблемы в связи с медленнной обработкой документов.
Сервер - 6 ядерный Xeon 32х битная ось (1С 32-х битная), 4 Гб памяти диски в RAID 10
Анализировал причины медленной работы, обнаружил следующую картину:
top - 15:03:56 up 7 days, 19:59, 2 users, LOAD average: 1.45, 1.46, 1.48 Tasks: 307 total, 2 running, 305 sleeping, 0 stopped, 0 zombie Cpu(s): 12.7 %us, 0.4%sy, 0.0%ni, 86.1%id, 0.7%wa, 0.1%hi, 0.1%si, 0.0%st Mem: 4138716k total, 3953172k used, 185544k free, 93440k buffers Swap: 7847744k total, 468k used, 7847276k free, 2467796k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27447 usr1cv81 20 0 1102m 810m 45m S 0 20.0 227:33.13 /opt/1C/v8.1/i386/rphost -range 1560:1591 -reghost fileserver 27437 usr1cv81 20 0 179m 46m 15m S 0 1.2 2:17.93 /opt/1C/v8.1/i386/rmngr -port 1541 9857 postgres 20 0 117m 92m 37m S 0 2.3 0:22.14 postgres: postgres alex_upp 192.168.0.111(58279) idle 27435 usr1cv81 20 0 80784 18m 10m S 0 0.4 0:02.21 /opt/1C/v8.1/i386/ragent -daemon 27268 postgres 20 0 76492 49m 37m S 0 1.2 2:19.29 postgres: postgres upp_vsm 192.168.0.111(51107) idle 24753 postgres 20 0 75992 50m 37m R 100 1.3 42:47.80 postgres: postgres semen_upp 192.168.0.111(56357) SELECT 32021 postgres 20 0 73652 48m 37m S 0 1.2 4:08.24 postgres: postgres upp_vsm 192.168.0.111(39340) idle 26312 postgres 20 0 68344 45m 37m S 0 1.1 1:57.18 postgres: postgres upp_vsm 192.168.0.111(46476) idle 24419 postgres 20 0 68096 46m 37m S 0 1.2 108:35.61 postgres: postgres semen_upp 192.168.0.111(58796) idle 24420 postgres 20 0 67452 45m 37m S 0 1.1 44:12.78 postgres: postgres semen_upp 192.168.0.111(58797) idle 24381 postgres 20 0 67032 44m 37m S 0 1.1 63:19.57 postgres: postgres semen_upp 192.168.0.111(58782) idle 9277 postgres 20 0 64144 38m 33m S 0 1.0 11:06.04 postgres: postgres semen_upp 192.168.0.111(44129) idle 24418 postgres 20 0 63596 41m 36m S 0 1.0 65:05.03 postgres: postgres semen_upp 192.168.0.111(58795) idle 13124 postgres 20 0 61160 18m 16m S 0 0.5 0:00.10 postgres: postgres alex_upp 192.168.0.111(47845) idle 31106 postgres 20 0 58780 10m 784 S 0 0.3 42:58.61 postgres: autovacuum launcher process 30371 root 20 0 56480 29m 536 S 0 0.7 1:01.18 /usr/sbin/hasplmd -s
Постгри загружает всего одно ядро обработкой выборки, и общая загрузка проца всего 12%. Есть ли способ заставить его раскидывать нагрузку по остальным ядрам?
Буду благодарен за любую помощь, спасибо
Во-первых, из данных видно,
Во-первых, из данных видно, что у вас кушает процессор 1C-овские демоны, а не PostgreSQL
Во-вторых, у вас неэффективно используется память: из 4G под просто кэш отдано 2.4G и ещё 0.7G свободно.
Поэтому смотрите postgresql.conf на предмет настроек памяти.
Что касается ядер, то разумеется, что один процесс может использовать единовременно только одно ядро и PostgreSQL здесь не при чём - такова работа операционной системы.
спасибо за ответВо-первых,
спасибо за ответ
Во-первых, из данных видно, что у вас кушает процессор 1C-овские демоны, а не PostgreSQL
а как же вот эта строчка :
24753 postgres 20 0 75992 50m 37m R 100 1.3 42:47.80 postgres: postgres semen_upp 192.168.0.111(56357) SELECTиз которой следует что 100% времени ядро проводит за выборкой из базы semen_upp. при это время все остальные запросы к другим базам находятся в режиме ожидания (idle).
9857 postgres 20 0 117m 92m 37m S 0 2.3 0:22.14 postgres: postgres alex_upp 192.168.0.111(58279) idleТ.е. вместо того что бы направить эти другие процессы(запросы) на другие ядра постгри ждет освобождения одного ядра. Это ярко проявлялось при попытке открыть в момент выполнения запроса на semen_upp любой справочник, находящийся в другой базе - почти 10 мин заняла эта процедура.
Во-вторых, у вас неэффективно используется память: из 4G под просто кэш отдано 2.4G и ещё 0.7G свободно.
спасибо что обратили на это внимание, не видел даже (
Что касается ядер, то разумеется, что один процесс может использовать единовременно только одно ядро и PostgreSQL здесь не при чём - такова работа операционной системы.
да, но ведь каждый запрос, тем более к разным базам - это отдельные процесс? почему бы им не висет в idle а распределится по свободным ядрам. На одном форуме меня уверили что в RedHat ES так и происходит.
зы Подскажите а нет ли на форуме опции цитирования? не очень удобно отвечать на Ваши посты без нее (
а как же вот эта строчка : А
а как же вот эта строчка :
А вот эта строчка как раз и показывает, что у вас используется несколько ядер. Потому что на одноядерной системе 100% это максимально возможное использование CPU. А если сложить ваши данные получается >100%. Как же такое может быть? Может, на многопроцессорных системах. Потому что используются другие ядра/процессоры
да, но ведь каждый запрос, тем более к разным базам - это отдельные процесс?
Нет. Процесс - это экземпляр программы, а не запрос, который обрабатывает эта программа. В вашем случае, при инициировании соединения создаётся процесс. Однако, все запросы, выполняемые в рамках этого процесса не обязаны бегать по ядрам.
Попробуйте установить программу mpstat и посмотреть результаты её работы