Начальная страница › Форумы › PostgreSQL › Вопросы по SQL и другие аспекты работы PostgreSQL

узкие места

Posted Июнь 5th, 2009 by gayunovdv
in

День добрый.
Есть определенная проблема.
Сервер: 2х4 ксеона, рэйд 3 зеркала, диски сата
OS: SuSE 10.2 Ent Server
Postgres: "PostgreSQL 8.3.3 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.1" (от 1С 8.1 patch)
Linux'овый 1С 8.1.13 (Конфигурация не стандартная) на этом же сервере
Настраивал как обычно сервер. Параметры памяти в конфиге крутил. Вообщем в обычном режиме работы база крутиться хорошо. Но предприятие занимается молочной продукцией, и у них есть партионный учёт. И когда они запускают групповую обработку документов, то всё происходит медленее чем было при MS SQL 2005. При этом и сервер приложений 1с 8.1 и postgres ложатся на один виртуальный проц.
Вопрос:
1)Можно ли заставить postgreSQL использовать для обработки определённый физический или виртуальный процессор?
2)Как определить узкое место при обработке?
Включил log_min_duration_statement = 0 - как мне теперь проанализировать данные?

3)Есть ли смысл включать enable_bitmapscan, или выключать fsync?

‹ Загрузка КЛАДР в PostgreSQL Где можно почитать про create implicit sequence ? ›

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Выключать fsync

On Июнь 5th, 2009 admin says:

Выключать fsync не советую - целостность данных всё-таки должна быть на 1-м месте.
Надо смотреть какие запросы загружают сервер, смотреть план этих запросов и анализировать их на предмет создания необходимых индексов.
Насколько мне известно, PostgreSQL в распределении нагрузки полагается на операционную систему и такми образом указать какие-то отдельные процессоры не получится.

Далее вопросы: сколько оперативки? какой у вас рейд? На скольки дисках?
Используете ли вы отдельные диски для WAL или и сама база и WAL у вас на одном логическом диске?
Включен ли вообще WAL, оптимальны ли его настройки?
По поводу памяти - что крутили и даёт ли это кручение какой-либо эффект?

Далее советую ещё посмотреть в настройках ОС такие параметры ядра как
vm.dirty_background_ratio
vm.dirty_ratio

Параметры

On Июнь 11th, 2009 gayunovdv says:

1csrv:/data/pgsql/data # cat /proc/sys/vm/dirty_ratio
16
1csrv:/data/pgsql/data # cat /proc/sys/vm/dirty_background_ratio
4

4Гб оперативки.

1csrv:/data/pgsql/data # cat /proc/meminfo
MemTotal: 8309724 kB
MemFree: 1014064 kB
Buffers: 39076 kB
Cached: 6817684 kB
SwapCached: 0 kB
Active: 3086112 kB
Inactive: 4062192 kB
HighTotal: 7470336 kB
HighFree: 760280 kB
LowTotal: 839388 kB
LowFree: 253784 kB
SwapTotal: 8393920 kB
SwapFree: 8393788 kB
Dirty: 1024 kB
Writeback: 0 kB
AnonPages: 288460 kB
Mapped: 250408 kB
Slab: 123032 kB
CommitLimit: 12548780 kB
Committed_AS: 2772500 kB
PageTables: 3592 kB
VmallocTotal: 112632 kB
VmallocUsed: 17560 kB
VmallocChunk: 92512 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB

Процессоры два - 4-х ядерника:
1csrv:/var/lib/pgsql/data # cat /proc/cpuinfo processor
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5410 @ 2.33GHz
stepping : 10
cpu MHz : 2333.601
cache size : 6144 KB

Рейд - два зеркала - диски сата.
База на отдельном логическом диске.

Все настройки стандартные для патченного постгреса от 1с. Кроме:
shared_buffers = 2GB
work_mem = 1024MB
#самая большая таблица 1598Мб
maintenance_work_mem = 1100MB
synchronous_commit = off
effective_cache_size = 2048MB
checkpoint_segments = 32

Вот долгая операция, если я всё правильно понял:

LOG:  duration: 9.910 ms  execute <unnamed>: SELECT
	'?а?????????????Ж???П?в???????А?????г?Б???Г??'::mvarchar AS f_1,
	'?а?????????????Ж???П ?В???????А???? ?? ?Г?Б???Г??'::mvarchar AS f_2,
	_Document431_Q_000_T_001._IDRRef AS _sf_2RRef,
	_Document431_Q_000_T_001._Number AS f_3,
	_Document431_Q_000_T_001._Date_Time AS _sf_1,
	_Document431_Q_000_T_001._Posted AS f_4,
	SUBSTR(_Document431_Q_000_T_001._Fld11232, (CASE
	WHEN 1 < 1
	THEN 1
	ELSE 1
	END)::int4, (999)::int4) AS f_5,
	_Document431_Q_000_T_001._Fld11233RRef AS f_6,
	_Document431_Q_000_T_001._Fld11234RRef AS f_7,
	_Document431_Q_000_T_001._Fld11235RRef AS f_8,
	_Document431_Q_000_T_001._Fld11236RRef AS f_9,
	_Document431_Q_000_T_001._Fld11237RRef AS f_10,
	_Document431_Q_000_T_001._Fld11238RRef AS f_11,
	_Document431_Q_000_T_001._Fld11239RRef AS f_12,
	_Document431_Q_000_T_001._Fld11240RRef AS f_13,
	SUBSTR(_Document431_Q_000_T_001._Fld11241, (CASE
	WHEN 1 < 1
	THEN 1
	ELSE 1
	END)::int4, (999)::int4) AS f_14,
	_Document431_Q_000_T_001._Fld11242RRef AS f_15,
	_Document431_Q_000_T_001._Fld11243 AS f_16,
	_Document431_Q_000_T_001._Fld11244 AS f_17,
	_Document431_Q_000_T_001._Fld11245RRef AS f_18,
	_Document431_Q_000_T_001._Fld11246RRef AS f_19,
	_Document431_Q_000_T_001._Fld11247 AS f_20,
	_Document431_Q_000_T_001._Fld11248 AS f_21,
	_Document431_Q_000_T_001._Fld11249 AS f_22,
	_Document431_Q_000_T_001._Fld11250RRef AS f_23,
	_Document431_Q_000_T_001._Fld11251_TYPE AS f_24,
	_Document431_Q_000_T_001._Fld11251_RTRef AS f_25,
	_Document431_Q_000_T_001._Fld11251_RRRef AS f_26,
	_Document431_Q_000_T_001._Fld11252_TYPE AS f_27,
	_Document431_Q_000_T_001._Fld11252_RTRef AS f_28,
	_Document431_Q_000_T_001._Fld11252_RRRef AS f_29,
	_Document431_Q_000_T_001._Fld11253RRef AS f_30,
	_Document431_Q_000_T_001._Fld11254 AS f_31,
	_Document431_Q_000_T_001._Fld11255 AS f_32,
	_Document431_Q_000_T_001._Fld11256RRef AS f_33,
	_Document431_Q_000_T_001._Fld11257RRef AS f_34,
	_Document431_Q_000_T_001._Fld11258RRef AS f_35,
	_Document431_Q_000_T_001._Fld11259RRef AS f_36,
	_Document431_Q_000_T_001._Fld11260 AS f_37,
	_Document431_Q_000_T_001._Fld11261RRef AS f_38,
	_Document431_Q_000_T_001._Fld11262RRef AS f_39,
	_Document431_Q_000_T_001._Fld11263RRef AS f_40,
	_Document431_Q_000_T_001._Fld11264RRef AS f_41,
	_Document431_Q_000_T_001._Fld11265RRef AS f_42,
	_Document431_Q_000_T_001._Fld11266RRef AS f_43,
	_Document431_Q_000_T_001._Fld11267RRef AS f_44,
	_Document431_Q_000_T_001._Fld11268 AS f_45,
	_Document431_Q_000_T_001._Fld11269 AS f_46,
	SUBSTR(_Document431_Q_000_T_001._Fld11270, (CASE
	WHEN 1 < 1
	THEN 1
	ELSE 1
	END)::int4, (999)::int4) AS f_47,
	SUBSTR(_Document431_Q_000_T_001._Fld11271, (CASE
	WHEN 1 < 1
	THEN 1
	ELSE 1
	END)::int4, (999)::int4) AS f_48,
	_Document431_Q_000_T_001._Fld11272 AS f_49,
	_Document431_Q_000_T_001._Fld11273RRef AS f_50,
	SUBSTR(_Document431_Q_000_T_001._Fld11274, (CASE
	WHEN 1 < 1
	THEN 1
	ELSE 1
	END)::int4, (999)::int4) AS f_51,
	_Document431_Q_000_T_001._Marked AS f_52
	FROM
	_Document431 _Document431_Q_000_T_001
	WHERE
	_Document431_Q_000_T_001._Date_Time > '2009-05-28 00:00:00'::timestamp AND _Document431_Q_000_T_001._Date_Time < '2009-05-30 00:00:00'::timestamp
	ORDER BY
	_Document431_Q_000_T_001._Date_Time,
	_Document431_Q_000_T_001._IDRRef

Какие будут идеи?

Попробуйте

On Июнь 11th, 2009 admin says:

Попробуйте поставить:
dirty_ratio = 60
dirty_background_ratio = 20
может станет чуть получше.

Идея одна - выполняйте на запрос EXPLAIN и смотрите план запроса.
autovacuum включён? проверьте на всякий случай как поведёт себя запрос при ручном выполнении VACUUM на используемые в запросе таблицы.

Чуть лучше

On Июнь 11th, 2009 gayunovdv says:

Да чуть лучше стало, если документ проводился 20 секунд, то сейчас 18...

План запроса

On Июнь 11th, 2009 gayunovdv says:

Вот такой вот план запроса

QUERY PLAN                                                                      
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=1417.98..1419.02 rows=416 width=733) (actual time=4.189..4.295 rows=454 loops=1)
   Sort KEY: _date_time, _idrref
   Sort Method:  quicksort  Memory: 474kB
   ->  Bitmap Heap Scan ON _document431 _document431_q_000_t_001  (cost=16.53..1399.88 rows=416 width=733) (actual time=0.140..2.430 rows=454 loops=1)
         Recheck Cond: ((_date_time > '2009-05-28 00:00:00'::timestamp without time zone) AND (_date_time < '2009-05-30 00:00:00'::timestamp without time zone))
         ->  Bitmap INDEX Scan ON _documen431_bydocdate_tr  (cost=0.00..16.43 rows=416 width=0) (actual time=0.114..0.114 rows=470 loops=1)
               INDEX Cond: ((_date_time > '2009-05-28 00:00:00'::timestamp without time zone) AND (_date_time < '2009-05-30 00:00:00'::timestamp without time zone))
 Total runtime: 4.484 ms
(8 rows)

Что с VACUUM?

On Июнь 11th, 2009 admin says:

Что с VACUUM?
и с WAL?

on

On Июнь 11th, 2009 gayunovdv says:

Он же по умолчанию включен...
autovacuum = on

А какие должны быть параметры
enable_bitmapscan =
enable_hashagg =
enable_hashjoin =
enable_indexscan =
enable_mergejoin =
enable_nestloop =
enable_seqscan =
enable_sort =
enable_tidscan =

Они по умочанию выключены? Может попробывать включить GEQO?

Проверьте РАБОТАЕТ ли

On Июнь 11th, 2009 admin says:

Проверьте РАБОТАЕТ ли он?
Выполните VACUUM на таблицы, использованные в запросе и запустите запрос снова.
Что с WAL?

Сделал вакуум над таблицами

On Июнь 11th, 2009 gayunovdv says:

Сделал вакуум над таблицами вручную, повторил запрос. По времени выполняется так же...

Сколько записей в

On Июнь 11th, 2009 admin says:

Сколько записей в таблице?
Что-то из плана запроса не пойму, если индекс на поле
_Document431_Q_000_T_001._Date_Time?
Если да, можно попробовать ещё создать составной индекс на поля
_Document431_Q_000_T_001._Date_Time и _Document431_Q_000_T_001._IDRRef

WAL

On Июнь 11th, 2009 gayunovdv says:

WAL включен, логи делаются на другой логический диск без базы.

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Back to top

(С) Виктор Вислобоков, 2008-2023