powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / 12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
18 сообщений из 18, страница 1 из 1
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33887586
Roaming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброго времени суток.

Первоначальные данные:
OC - FreeBSD 6.1 /AMD 3200+/ 1G RAM/ SATA HDD.
PostgreSQL 8.1
БД ~ 12G (40млн rows)

postgresql.conf:

max_connections = 180
shared_buffers = 4000
temp_buffers = 1000
work_mem = 850000
max_fsm_pages = 407000
fsync = off
effective_cache_size = 102400
stats_start_collector = on
stats_command_string = on
stats_row_level = on
sort_mem = 5024 (опции небыло. Добавил, БД приняла.)

Возник следующий вопрос:
Средний SELECT выполняеться достаточно быстро.
Но если SELECT содержит ORDER BY то длиться он ~15 мин.
Если UNION + ORDER + COUNT то все 10 часов.

Больше всего меня поразили показатели нагрузок в момент такого запроса:
IOSTAT ~ 2.00 MB/s (Вовремя REINDEX - 50MB/s)
SWAP < 1Mb
CPU Бездействие ~ 90%
RAM Свободно ~ 40%

Чего ему не хватает ?

P.S. Ошибок в логах нет.
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33888298
domanix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Прежде всего нужно понгять сколько записей перемалывает постгрес для получения результата.
Для этого посмотреть какие планы у запросов- потому как ордер бай по таблице с несколткими миллионами записей- приводит к предварительной сортировке этих даыннах - что на любом сервере затруднитеольно- о сем кстати и говорит вроде как бездействие системы - поскольку наверняка идет сортировак а данных на лискве( в памяти такой обьем не поместился) и все упирается в медленность дисковой подсистемы..
Можно также почитать про тонкую настройку постгреса- может увеличить некоторые области памяти. В общем смотреть можно в разные места- и решений твоей проблемы может быть много.Важно чтобы ты понял - где у тебя тонкое место.
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33888780
Roaming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я 2-е недели занимался тюнингом БД.
крутил около 20 параметров.
Дисковая подсистема НЕ нагружена. Я для этого показывал вывод iostat.
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33888925
domanix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
тогда смотри в сторону запроса - сколько данных ему нужно перелопатить чтобы получить результат? таблицы то не малые ...
order by - не по индексу?
сортируются миллионы записей?

у тебя
shared_buffers = 4000 - под буффер страниц отдано 4000*8кб=32 мега- маловато для системы с гигом памяти...
попробуй так:
shared_buffers = 32768 -отдадим 256 мегов под буффер страниц

sort_mem=10240 - 10 мегов на сортировку для каждого процесса
кроме того set_config - позволяет изменять этот параметр для конкретного процесса - что дает возможность изменить обьем памяти выделенный под сортировку - если в этом процессе выполняется сложный запрос требующий много памяти на сортировку.

поиграйся этими параметрами ..
если же ты этим уже занимался - то дай результаты чтобы мы могли тут оценить влияние этих параметров на производительность на твоих данных..
иначе мы просто гадаем на кофейной гуще...
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33888970
domanix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
и уменьши work_mem = 850000 - ты туда почти всю память запулил .. что по моему хреновато...

дай гдето ну сажем 100 мегов..
work_mem = 100000
посмотри что измениться.. может даже уменьшить надо - ибо эта память выделяется для каждого процесса.
опять таки может проще эту память изменять прямо из сессии перед выполнением запроса с большой сортировкой..
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33888985
domanix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А вобще мне кажется что дело в неоптимальных запросах...
Настройки сервака - конечно может и могут изменить ситуацию - не не не в разы (IMHO) - а вот переосмысление запросов - может изменить ситуацию кардинально...
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33890231
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
автор
IOSTAT ~ 2.00 MB/s

Это не значит, что дисковая подсистема не нагружена.
Очень как раз похоже на то, что план запроса содержит index scan, который и совершает беспорядочные чтения, прогружая всю дисковую подсистему.
Без вывода vmstat во время запроса, описания таблицы, индексов и плана запроса здесь не обойтись.
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33894741
mwolf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО запросы не ускоришь настройками сервера
Давай лучше сюда тяжёлые запросы и планы их выполнения
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33898611
Roaming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Принял к сведению!
Щас пытаюсь поправить, как только что - то появиться попытаюсь описать ?

P.S. У кого то запрос ~[SELECT * FROM table ORDER BY column LIMIT 1000] отрабатывал на таких объемах меньше 5 минут ?
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33899044
domanix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ORDER BY по неиндекированным данным размером несколько миллионов записей по лпределению не быстрая операция. особенно есмли запись широкая ( десяток полей различного длинного типа..)...
Возможно поможет индекс - по сортируемым полям.. Панацеи не существует!! Нужно смотреть по конкретным метсданным и конкретной задаче - как ее можно ускорить...
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33899069
Funny_Falcon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
SELECT * FROM table ORDER BY column LIMIT  1000 
Если есть индекс по column и vacuum выполняется регулярно (настроен autovacuum) - больше пяти секунд он не может выполняться, и без разницы 1G, 12G или 100G
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33899153
Kruchinin Pahan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Roaming P.S. У кого то запрос ~[SELECT * FROM table ORDER BY column LIMIT 1000] отрабатывал на таких объемах меньше 5 минут ?

Вот я одного не понимаю: а нафига в этом запросе "LIMIT 1000"? Почему не 1, и не 10000? LIMIT на время выполнения запроса в данном случае никак не влияет.
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33899252
Roaming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
domanix
у тебя
shared_buffers = 4000 - под буффер страниц отдано 4000*8кб=32 мега- маловато для системы с гигом памяти...
попробуй так:
shared_buffers = 32768 -отдадим 256 мегов под буффер страниц

sort_mem=10240 - 10 мегов на сортировку для каждого процесса
кроме того set_config - позволяет изменять этот параметр для конкретного процесса - что дает возможность изменить обьем памяти выделенный под сортировку - если в этом процессе выполняется сложный запрос требующий много памяти на сортировку.

поиграйся этими параметрами ..


work_mem = 100000
sort_mem = 10240
shared_buffers =22937

Вроде добавилось 40-60% производительности. Но появился swap буду что - то урезать.

Вот БОЛЬШОЙ статистический query


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
select ip, sum(count), sum(count_total)  from  
 (select 
    serverdb.ip, 
    count(rec_id) as count_index, 
     0  as count_total 
  from serverdb , ip 
  where ip.ip LIKE serverdb.ip || '%' 
     and ip.status =  0  group by serverdb.ip 
 union 
select 
serverdb.ip, 
 0 , 
count(rec_id) 
from serverdb , ip where ip.ip LIKE serverdb.ip || '%' group by serverdb.ip   ) as great_query 
 group by ip;
На нем я тестирую.
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33899406
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kruchinin Pahan Вот я одного не понимаю: а нафига в этом запросе "LIMIT 1000"? Почему не 1, и не 10000? LIMIT на время выполнения запроса в данном случае никак не влияет. выше сказано - при наличии индекса по набору полей, используемом в ORDER BY будет использован индекс. А именно индекс скан +луп. если индекс содержит не слишком много удаленных значений, то просмотрено будет не многим больше значений индекса чем число возвращаемых записей.
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33899463
domanix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Во первых - этот запрос можно значительно упростить - если не делать ДВА прохода по таблицм как делается сейчас.
Во вторых я чтото сильно сомневаюсь что обьединение таблиц p.ip LIKE serverdb.ip || '%' происходит по индексу-( даже если он есть).
Т.е. на лицо все оснавания считать этот запрос самым не оптимальным из возможных - т.е. именно изза того как написан запрос - ты и получаешь значительные тормаза...
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33899491
IgorNK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Во-первых, что касается
Roaming work_mem = 100000
sort_mem = 10240
shared_buffers =22937 прочтите следующее:

Documentation SaysSpecifies the amount of memory to be used by internal sort
operations and hash tables before switching to temporary disk
files. The value is specified in kilobytes, and defaults to 1024
kilobytes (1 MB). Note that for a complex query, several sort or
hash operations might be running in parallel; each one will be
allowed to use as much memory as this value specifies before it
starts to put data into temporary files. Also, several running
sessions could be doing such operations concurrently. So the
total memory used could be many times the value of
work_mem; it is necessary to keep this fact in mind when
choosing the value. Sort operations are used for ORDER BY,
DISTINCT, and merge joins. Hash tables are used in hash
joins, hashbased aggregation, and hashbased processing of IN
subqueries.
CommentsFormerly sort_mem, this setting name has been changed to reflect
its expanded role in governing more than just sorts.
Work_mem is a direct tradeoff. Adjust it upwards for: large
databases, complex queries, lots of available RAM. Adjust it
downwards for: low available RAM, or many concurrent users.
Finding the right balance spot can be hard.
Another way to set this value is to monitor the Postgres temp files
(in PGDATA/base/DB_OID/pgsql_tmp) and adjust sort_mem
upward if you see a lot of queries swapping from these temp files.
Also keep in mind that this parameter can be adjusted per
connection. So if you only have a few really large queries, you can
increase the work_mem for them before query execution, and leave
it low for the rest of the connections.

Ваше sort_mem на самом деле либо игнорируется вообще, либо переустанавливает work_mem , что еще хуже. Уберите, а если интересует, то сделайте запрос, какое значение фактически используется.
Во-вторых, ваши запросы из-за LIKE виполняются посл. сканированием. Замените двумя неравенствами, чтобы использовать индекс.
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33899735
Roaming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
IgorNK
Ваше sort_mem на самом деле либо игнорируется вообще, либо переустанавливает work_mem , что еще хуже. Уберите, а если интересует, то сделайте запрос, какое значение фактически используется.
Во-вторых, ваши запросы из-за LIKE виполняются посл. сканированием. Замените двумя неравенствами, чтобы использовать индекс.

спасибо, поправил
pgsql говорит :
work_mem 100000
попробуем, как на производительности скажется.
...
Рейтинг: 0 / 0
12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
    #33899813
Roaming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Carrie автор
IOSTAT ~ 2.00 MB/s

Это не значит, что дисковая подсистема не нагружена.
Очень как раз похоже на то, что план запроса содержит index scan, который и совершает беспорядочные чтения, прогружая всю дисковую подсистему.
Без вывода vmstat во время запроса, описания таблицы, индексов и плана запроса здесь не обойтись.

Отрабатывает 50 запросов
~ SELECT count(*) FROM tabler WHERE o='6101' AND n='1268'
~ SELECT id FROM server WHERE name='http://server.web.ru'
~ UPDATE tabl SET k=0.1 WHERE id='3805'

vmstat расшифруйте
(Если не сложно расшифруйте)

iostat -w 5
tty ad4 ad5 cpu
tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id
1 1000 20.16 154 3.03 0.68 0 0.00 24 0 10 3 64
0 775 19.85 147 2.85 0.00 0 0.00 17 0 7 1 75
0 933 18.80 152 2.79 0.00 0 0.00 31 0 9 1 59
0 845 22.36 148 3.23 0.00 0 0.00 44 0 9 3 44
0 1123 26.62 156 4.05 0.00 0 0.00 34 0 8 2 56
0 756 21.03 166 3.41 0.00 0 0.00 23 0 11 2 63
0 1072 23.50 155 3.55 0.00 0 0.00 30 0 10 2 59
0 569 25.30 169 4.18 0.00 0 0.00 42 0 9 2 47

Тут без изменений


Одна из таблиц
CREATE TABLE "tables" (
"t" int4 not null,
"у" int4 not null,
"w" float not null default 100,
"validat" char(1) default 't'
) WITHOUT OIDS;
ALTER TABLE ONLY "tables" ADD CONSTRAINT tables_pkey PRIMARY KEY (t,y);
CREATE INDEX tables_t ON tables (t);
CREATE INDEX tables_y ON tables (y);
...
Рейтинг: 0 / 0
18 сообщений из 18, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / 12G база. Тюнинг БД. Медлиный SELECT + ORDER BY
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]