powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
22 сообщений из 22, страница 1 из 1
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34855938
pg_beginner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Разрешите спросить вот прямо строчкой из FAQ'а у уважаемых гуру :)
Ибо по-видимому, это мой случай :/

По пунктам опять же из FAQ'а расписываю информацию:

1. Версия PG - 7.4.1. ОС - AIX 5.3. "Железо" - Сервер IBM P570, 16-процессорный двухядерный PowerPc. 64 Gb оперативки. База и datadir установлены в раздел 1TB.
2. Какие настройки? Особенно интересуют изменения в файле postgresql.conf

Основные изменения:
Установил shared_buffers в 2 Gb (c 4-мя гигами стартовал, но вываливался при обращении к данным).
sort_mem - 1 Gb.
vacuum_mem 4 Gb.
wal_buffers - 4 Mb
effective_cache_size - 1 Gb.

3. Есть ли еще что-то активно работающее на этой машине?
пока нет, и вся эта махина молотит вхолостую 8)

4. Тормоза на каких запросах? Каков объем данных?
Не то что бы тормоза, но 10% прирост производительности в сравнении с обычной рабочей станцией (3 ГГц CPU, 512 Mb оперативки) - это мягко говоря, не то, что я ждал 8)

делаем простую выборку, в таблице около 108 тыс. записей:

"локалка":
Код: plaintext
1.
2.
QUERY PLAN
Seq Scan on weight_carriage  (cost= 0 . 00 .. 2443 . 96  rows= 108096  width= 84 ) (actual time= 0 . 009 .. 89 . 387  rows= 108096  loops= 1 )
Total runtime:  148 . 520  ms

IBM:

Код: plaintext
1.
2.
QUERY PLAN
Seq Scan on weight_carriage  (cost= 0 . 00 .. 2308 . 96  rows= 108096  width= 84 ) (actual time= 0 . 006 .. 124 . 848  rows= 108096  loops= 1 )
Total runtime:  200 . 357  ms

seqscan вообще тормозит!


подключаем индекс: explain analyse select * from weight_carriage where carr_id=10000;

"локалка"
Код: plaintext
1.
2.
3.
QUERY PLAN
Index Scan using weight_carriage_pkey on weight_carriage  (cost= 0 . 00 .. 4 . 02  rows= 1  width= 84 ) (actual time= 0 . 020 .. 0 . 020  rows= 0  loops= 1 )
  Index Cond: (carr_id =  10000 )
Total runtime:  0 . 056  ms

IBM:
Код: plaintext
1.
2.
3.
QUERY PLAN
Index Scan using weight_carriage_pkey on weight_carriage  (cost= 0 . 00 .. 3 . 90  rows= 1  width= 84 ) (actual time= 0 . 016 .. 0 . 016  rows= 0  loops= 1 )
  Index Cond: (carr_id =  10000 )
Total runtime:  0 . 046  ms


В принципе, по секундомеру замерял отработку сложных отчетов - в среднем процентов на 10%
стали быстрее вываливаться (например, вместо 45 секунд - 38-40).

Разве это РОСТ производительности???


5. А что с дисковой подсистемой?
6. А с CPU?


Самое интересное, что при выполнении запросов postgres отжирает 13-14% CPU, 10-12% pagespace, то есть - ресурсы-то берёт, но НА ЧТО он их тратит??

8. Когда последний раз делался VACUUM FULL ANALYZE?

регулярно каждый раз, после правки файла postgresql.conf.

Ребят, подскажите, кто что знает? Я пока в растерянности.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34855974
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вы напрасно ожидали увеличения производительности на одном запросе.
В p570 стоят процессоры p5 с частотой 1.65 (вероятнее всего). Может быть 1.9
Современные x86 процессоры гораздо быстрее p5 в specint. Сравните сами на spec.org
А вот когда у вас будет одновременно исполняться сотни и тысячи запросов, тогда вы получите другие результаты по сравнению с PC. Когда самые конкуретные индексы уложаться в 70-100мб кеша L3 вашего сервера вы, вероятно, это почувствуете.

Тем не менее, современный 4x сокетный х86 сервер с 4х ядерными процессорами скорее всего будет заметно быстрее.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34855984
st_serg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вы замеры производили при работе одной сессии?
а если запустить, скажем, 32 более менее активных сессии одновременно?
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34856011
pg_beginner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
т.е. нормальный прирост будет ощущаться только в случае конкуретной работы с базой?
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34856060
Nick Gazaloff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
У вас версия PostgreSQL 2003 года. Для начала обновите до последней версии, потом уже есть смысл разговаривать.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34856116
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pg_beginner пишет:

> В принципе, по секундомеру замерял отработку сложных отчетов - в среднем
> процентов на 10%
> стали быстрее вываливаться (например, вместо 45 секунд - 38-40).
>
> Разве это РОСТ производительности???

Производительностьв вообще - это кол-во операций в единицу времени.
А вы - секундомером. Замерянное время вообще в СУБД ничего не определяет.
Непоказательно. Ну а остальном вам уже вроде бы сказали.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34856123
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pg_beginnerт.е. нормальный прирост будет ощущаться только в случае конкуретной работы с базой?
ну конечно же, единичный p5 - далеко не самый быстрый процессор.
Мощь вашего сервера будет заметна, когда будет большое число конкурентных запросов и активная стрельба по памяти. Тут и должны проявятся архитектурные преимущества: больште кеши, широкая шина к памяти и т.д.

Господа, которые советуют перейти на pg8, совершенно правы. Это нужно сделать немедленно, если только у вас нет каких-то застарелых несовместимостей, накопленных в старом проекте.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34856415
Oleg Bartunov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Времени нет, поэтому очень кратко:

Откуда вы взяли, что надо выставлять такие параметры ?
Например, sort_mem=1GB это просто ужас !
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34856433
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nick GazaloffУ вас версия PostgreSQL 2003 года. Для начала обновите до последней версии, потом уже есть смысл разговаривать.
Если нет возможности перейти на 8.2, то хотя бы на топовую 7.4.18.

ЗЫ В дополнение к остальным. PG не умеет параллелить еденичные запросы, поэтому для одного клиента условно "по барабану" сколько у Вас процессоров. Хоть 512. Условно - потому, что ОС немного, но все-таки отжирает, автовакуум много но иногда, ну и т.д.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34856593
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Олег Бартунов очень занятый человек, он выразался кратко.
sort mem обычно в раза в 32 меньше.
Вообще, нет смысла задирать все параметры, не понимая их смысла.
если у вас в руках оказался такой сервер, да еще и под AIX, следует более тщательно отнестись к OS, софту, настойкам и пр. В противном случае x86 сервер за $6000-10000 со свежим линуксом и постгресом из пакетов будет без всяких настроек работать много быстрее вашего монстра.

Если нет желания читать докментацию и рассылку postgresql.org, то можете взять для примера конфиг из spec.org
http://www.spec.org/jAppServer2004/results/res2007q3/jAppServer2004-20070606-00065.html
http://www.spec.org/jAppServer2004/results/res2007q3/jAppServer2004-20070606-00065.html#DBDatabase_SW_Config0
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34856725
pg_beginner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Oleg BartunovВремени нет, поэтому очень кратко:

Откуда вы взяли, что надо выставлять такие параметры ?
Например, sort_mem=1GB это просто ужас !
спасибо за конструктив!

а где ещё откровенные ошибки, кроме этого параметра?
укажите пожалуйста, если не сложно.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34856781
pg_beginner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вопрос такой - что конкретно даст переход на 8-ку?
в плане производительности. понятно что будет лучше.
интересует скорее, чем конкретно уступает 7.4?
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34856807
pg_beginner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrey DaeronЗЫ В дополнение к остальным. PG не умеет параллелить еденичные запросы, поэтому для одного клиента условно "по барабану" сколько у Вас процессоров.
вот. более-менее проясняется.

спасибо добрый человек :)
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34857041
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pg_beginnerвопрос такой - что конкретно даст переход на 8-ку?
в плане производительности. понятно что будет лучше.
интересует скорее, чем конкретно уступает 7.4?
Гнусный вопрос. В общем и целом дофига улучшений. Начиная с оптимизатора, планировщика, индексов заканчивая автовакуумом и всякими асинхронными коммитами (в 8.3). Три мажорных ветки уже вышли, четвертая на подходе. Подробнее - в релизнотах на каждую версию.

ЗЫ Для конкретики "уступок" нужно знать что Вы используете. Для запроса "SELECT 1+1" серьезных улучшений небыло.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34857205
pg_beginner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну просто как обычно бывает - типа, о, да это же старье, кто ж на нём работает!
а реально разобраться - ну да, функционала добавилось. но чтоб обновил версию - и всё "летает" - нету такого.
поэтому и спрашиваю.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34857229
pg_beginner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
во, а запрос типа SELECT t1.f1, t2.f2 FROM table1 t1, table1 t2 WHERE t1.f_id=t2.f2
+ агрегатные ф-ии, подзапросы

для запросов такого типа - улучшения есть?

да и вообще, отклонились мы. разговор про оптимизацию под железяку. и почему не так быстро,
как ожидалось. тут вам спасибо - разъяснили про невозможность распараллелить запрос по процессорам.
а более крутая 8-ка, я так понимаю, будет быстрее шебуршить как на "локалке" так и на ibm.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34857380
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pg_beginnerво, а запрос типа SELECT t1.f1, t2.f2 FROM table1 t1, table1 t2 WHERE t1.f_id=t2.f2
+ агрегатные ф-ии, подзапросы

для запросов такого типа - улучшения есть?

а более крутая 8-ка, я так понимаю, будет быстрее шебуршить как на "локалке" так и на ibm.
1. Угу. По идее всякие вещи типа битмаповых индексов могут помочь ускориться.
2. Не факт. По крайней мере в начале стабильной ветки 8.2 многие заметили лёгкое уменьшение производительности по сравнению с 8.1. Сейчас толи никто не переходит, либо не признаётся, либо не тормозит
3. Было много изменений в ядре и оптимизаторе. "Обновил и летает" - это вряд ли, но некоторые видели убыстрения до 30%. Опять же за счет архитекутры (например партиционирование) можно ускорить еще сильнее.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34857820
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
у меня переход на 8-ку заметно поднял производительность.
Микрозадачи выглядят так:
- вызов 5-6 хранимых процедур (друг из друга) в одной транзакции.
- обновляется 5-6 таблиц и вставляется 200-300 записей.
На чистой базе получил скорость 120-150% от семерки.
На распухшей базе разница доходила до 200%.

При этом 7-ка показывала хуже чем линейную зависимость от размера транзакции. Например вставка в одной транзации 100 записей -10 мсек, 1000записей - 200мсек.
На 8-ке была почти линейная зависимость до 10 000 записей!

Второй плюс - заметил прирост %15 на 64битной сборке по сравнениею с 32битной (FreeBSD) по большим селектам на int8 и timestamp.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34867172
pg_beginner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ребята, я в шоке!
8.2.5 по различным замерам (моим) в среднем в два раза быстрее, чем 7.4.1.
не ожидал, честно.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34868294
alex_v13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
pg_beginner

авторОсновные изменения:
Установил shared_buffers в 2 Gb (c 4-мя гигами стартовал, но вываливался при обращении к данным).
sort_mem - 1 Gb.
vacuum_mem 4 Gb.
wal_buffers - 4 Mb
effective_cache_size - 1 Gb.

Для 64 GB памяти effective_cache_size можно ставить как минимум в половину этого объема,
sort_mem нужно урезать раз в 20 в зависимости от размеров ваших сортируемых выборок.

Еще - какой у вас размер базы на диске - влезает в кэш?

В восьмерке, если база часто обновляется включите автовакуум с небольшим интеревалом.

PS: не используйте секундомер - в консоли есть /timing :)
PPS: для назгрузочного тестирования юзайте специальные программы, например, JMeter.
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34868991
pg_beginner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex_v13 pg_beginner

авторОсновные изменения:
Установил shared_buffers в 2 Gb (c 4-мя гигами стартовал, но вываливался при обращении к данным).
sort_mem - 1 Gb.
vacuum_mem 4 Gb.
wal_buffers - 4 Mb
effective_cache_size - 1 Gb.

Для 64 GB памяти effective_cache_size можно ставить как минимум в половину этого объема,
sort_mem нужно урезать раз в 20 в зависимости от размеров ваших сортируемых выборок.

Еще - какой у вас размер базы на диске - влезает в кэш?

В восьмерке, если база часто обновляется включите автовакуум с небольшим интеревалом.

PS: не используйте секундомер - в консоли есть /timing :)
PPS: для назгрузочного тестирования юзайте специальные программы, например, JMeter.
за советы - спасибо! буду пробовать :)

по поводу timing - да я вообще-то в курсе. просто есть приложения, генерирующие отчеты.
в каждом отчете куча запросов, да ещё в циклах и так далее. Мне чтобы прикинуть эффективность работы, проще засечь общее время генерации отчетов. Я ж не доли секунд
ловлю, а в глобальном смысле - есть ли улучшения :)
...
Рейтинг: 0 / 0
У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
    #34919066
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
советую включить log_min_duration = 1000*N
в лог будут попадать запросы с длительностью исполнения более Nсек

очень полезно, поскольку вы будете видеть:
- дорогие запросы
- как они меняются от ваших действий c параметрами.
...
Рейтинг: 0 / 0
22 сообщений из 22, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / У меня МЕГАСЕРВЕР, но Postgres работает ужасно! Сделал что мог, не помогло! В чем грабли?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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