Заметил, что если в любой(!) и большой или маленькой таблице строчек примерно до 70 000, то операции insert/update/delete выполняются почти мгонвенно. Но вот если больше 70 000, то те же самые запросы начинают занимать все 100% ресурсов CPU и работают в десятки раз дольше. Пробовал на различных серверах. Запросов много - все они оч маленькие. Как только кол-во опускается менее 70 000 - то сново все летает.
Подскажите, что можно почитать на эту тему. Может можно еще что то потюнить.
Система:
Linux 2.6.22-r5 SMP
postgresql 8.1.9
8Gb Ram
Кроме постгреса других процессов на серваке нет.

в том то и дело что к примеру оч простые запросы



до 70 000 летают - а после тормазят.

postgresql.conf
max_connections = 10000
shared_buffers = 65536
temp_buffers = 800
work_mem = 65536
maintenance_work_mem = 131072
max_stack_depth = 2048
fsync = on
wal_buffers = 128
commit_delay = 1000
checkpoint_segments = 10
checkpoint_timeout = 900
effective_cache_size = 65536
random_page_cost = 4
redirect_stderr = on
log_rotation_size = 10240
stats_start_collector = on
stats_command_string = on
stats_block_level = on
stats_row_level = on
stats_reset_on_server_start = off
autovacuum = on
autovacuum_naptime = 90
max_locks_per_transaction = 80


Остальное по дефолту
База примерно 60 Gb
8Gb Ram (в свопе еще 214 кб)

PostreSQL начинающий Конфиг дисковой подсистемы? Контроллер? Размер кэша? Tablespaces?

диски 0+1 200Gb SATA 8mb кеш всего 4ре штуки
контроллер интеловский набортный
(!)Tablespaces? - это меня поставило в тупик - а как это смотреть?

ps -пробовали и на других серверах - диски побольше/поменьше, SATA/PATA/SCSI
все равно около 70 000 какие то тормаза - родилась идея может это наследие 12 битных систем?

возможно вы правы
hdparm -t /dev/mapper/hhacaafe

/dev/mapper/hhacaafe:
Timing buffered disk reads: 8 MB in 3.76 seconds = 2.12 MB/sec


и еще
top - 13:15:39 up 1 day, 55 min, 2 users, load average: 20.22, 17.90, 17.06

Есть ли способ (возможно есть уже готовые тесты) проверить что система слаба для такой нагрузки. Похоже придется писать обоснование - по тому прошу помощи.

ChameLe0nload average 20 - это огромное значение. Пытались определить откуда такая нагрузка?

как это можно сделать? какие есть методы? я использую команду top

авторSearching...
[ Results for search key : iometer]
[ Applications found : 0 ]

Gentoo (sync 06.09.07)
kernel 2.6.22-r5 SMP
Postgres postgresql-8.1.9
8Gb Ram
Кроме постгреса других процессов на серваке нет.

alex_v13 nedba

1. ~70000 строк - это ваша эмпирическая оценка для размера кеша определяемого
shared_buffers = 65536 относительно ваших объемов данных.
2. effective_cache_size = 65536 - мало, надо 1/2 - 2/3 от всего объема памяти на выделеном сервере.


Как раз за эти параметры я сейчас и бьюсь. При увеличении effective_cache_size - хотя бы в двое - система ведет себя так: после перезагрузки все запросы летают, через 20 минут начинают исполнятся дольше чем после перезагрузки раз в 10, через 4-5 часов система еле ворочает даже простой запрос типа SELECT * FROM tables1 LIMIT 1 . Помогает только перезапуск постгреса.

Отсюда вопрос - effective_cache_size - как сказано в документации http://www.postgresql.org/docs/8.2/interactive/runtime-config-query.html отвечает за распределение кеша для одной квери исходя из доступности кеша дискового и распределяемого ядром. Значит при большом количестве маленьких запросов к разным таблицам в памяти будут сидеть не данные страниц таблиц, а индексы этих таблиц. и каждая новая квери будет пытатся сначала выкинуть LRU чужих индексов и засунуть туда свои индексы, а потом только уже искать среди них условия своего селекта. А так же не сказанно, что индексы твоей квери доступны другим потокам обращающимся к той же таблице в это же время (из-за версионности(?)).

Вопрос первый - так ли я понял.
Вопрос вторй - надо ли тогда его делать все-таки большим и появится ли прирост производительности через некоторое время большой нагрузки.
Третий вопрос - как можно повлиять/настроить дисковый кеш, который управляется ядром (по тому, что постгрес не пытается брать на себя функции возложеные на операционку).