Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
Сервак: IBM E-Server 235 1.5 Гб оперативки. Тормоза жуткие. Все манипуляции, описанные в рекомендациях произвёл. КПД почти 0. Хотел поинтересоватсья. Может встречал кто статьи, посвящённые оптимизации работы сабжа, кроме переписок из мануала от PG??? --- "Нефига себе у вас запросы!!!", сказала база данных и подохла... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 11:20 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
darkfoxСервак: IBM E-Server 235 1.5 Гб оперативки. Тормоза жуткие. Все манипуляции, описанные в рекомендациях произвёл. КПД почти 0. А можно в этом месте поподробнее? 1. Версия PG? 2. Какие настройки? 3. Есть ли что-то еще на этой машине? 4. Тормоза на каких запросах? Каков объем данных? 5. А что с дисковой подсистемой? darkfox Хотел поинтересоватсья. Может встречал кто статьи, посвящённые оптимизации работы сабжа, кроме переписок из мануала от PG??? Ну, а там не так много парамтеров которые спецефичны для PG и которые можно крутить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 13:52 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
Ну и еще желательно сказать какие манипуляции были сделаны. А то с телепатией не у всех хорошо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 13:56 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
Еще хорошо бы узнать, какие задачи решает сервер. У тебя, может быть, длинные, но редкие, запросы, у которых неудачно используется индекс, а мы тебе тут будем советовать чекпоинты почаще устраивать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 15:28 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
упс, в порыве рабочего дня забыл про главное. Сорь. :) Начну с конфига (postgresql.conf). версия: postgres (PostgreSQL) 8.0.9 под Gentoo. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Что касается основного бункера: Классика для тестирования больших запросов - лог squid'a. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. Дабы сильно не насиловать основной бункер, имеется View, отражающий текущий лог за месяц: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. нижеприведённый запрос уходит в себя на 48сек. +-10 :) А если соединить это с таблицей users по полю login(не больше 300 записей), то время вырастает ещё больше Код: plaintext 1. --- "Нефига себе у вас запросы!!!", сказала база данных и подохла... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 17:25 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
Ну а что explain говорит-то на этот запрос? И work_mem = 1248576 - это больше гига и вряд ли поможет, все равно в кэш уйдет.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 17:32 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
PS: то же касается и share_buffers - больше 10 000...15 000 на машинах с 1.5 ГБ ставить не имеет смысла, а у Вас 100 000 -это не описка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 17:35 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
если в squidlog часто и густо вставляются записи, то смысл кучи индексов на ней? имхо лучше запускать какойнить джоб, для предварительного агрегирования данных. на больших таблицах может иметь смысл партицирование ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 17:51 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
На серваке 1.5Гб оперативки. 2Alex_v13: 100000 не описка. я так понял, что это объём разделяемой памяти, используемой сервером. Соответственно 100000*8=800000 800000/1024=781Мб нет? ;\ Что касается индексов, то они имеют смысл всегда, т.к. для сервера быстрее сделать выборку из него, нежели перебирать всю таблицу. (другое дело, что у ПГ с ними трабла. Один тип вообще не рекомендуют использовать, другой и цепляется не всегда.) Что касается разукрупнения бункера(сводные таблицы и тп.), то с этим и так всё ясно. Но хотелось бы решить проблему "в лоб", т.к. аналогичная задача на Оракле при тех же условиях работает в ДЕСЯТКИ раз быстрее. Но уж на крайний случай единственное разумное решение вижу, чтобы поля URL и sURL вынести в отдельную таблицу, и тоже скажу про классификационные величины (method, mimetype) Однако делать не хочется ещё и по тому, что была задача аналогичная(технически) с товарооборотом компании. В ней 30млн уникальных позиций (в год) по оборотам. Данные из которых получают в режиме реального времени. Вобщем пока ещё раз делаю вывод, что FSF базы не готовы к большим объёмам данных. Печально. Но буду рад, если переубедит кто или ткнёт носом в ошибки и правильное решение. --- "Нефига себе у вас запросы!!!", сказала база данных и подохла... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 19:17 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
помойму запрос остается запросом во вюшке он или нет.. выиграша там помойму 0. или в посгря уже научилась вюшки быстрее запросов на таблицу выполнять?? :0 (почему-то большинство манагеров думают что ВСЕГДА код дороже оптимизить чем покупать новое жалезо...и настраивать софт.) и я тоже посоветую индексы нафих убить. , переделал на вставку данных пачками через copy(ну не посекундная же у вас тарификация а если хотите рубить конекты и отрубать пользователей по достижению лимита трафика то видимо всеравно пока вы сквиду будете об этом сообщять уйдет какое-то время т.е. превышение будет.. мне кажется надо это принять как должное и уже спокойно давать ему еще 15 минут покачать прнуху -угадал? :) и отдельно агрегировать + видимо имеет смысл побить таблицу squidlog например по месяцам. еще мона тригер повесить на инсерт в эту таблицу типа trigger on insert on squid_log update login_traf set traf=traf+NEW.traf where login=NEW.login... т.е. агрегируем на лету.. юзеров видимо не мильен.. так. что что особо не нагрузит вставку. ну как-то так.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 19:25 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
>Что касается индексов, то они имеют смысл всегда, т.к. для сервера быстрее сделать выборку из него, нежели перебирать всю таблицу. только не в случае когда у вас обновление и вставка в таблицу на несколько порядков больше чем чтение -тут стоит задуматся. перестройка индексов тоже нехилая операция. и посмотрите сколько занимают все ваши индексы по сравнению с самой таблицей(в килобайтах). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 19:30 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
вьюшки в ПГ медленнее обычного запроса!??! Убить индексы на таблицы?!?!? О_О сколько я помню, так индексы делались для ускорения поиска и запросов по таблице... или вы хотите сказать, что в ПГ индексы-дурной тон?! О_О И потом, индексы пополняются при вставке, а не перестраиваются... кажется(теперь я уже не уверен) Вобщем пока тихий УЖОС!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 20:11 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
Ну я не вижу собственно вляния индесов на обновление базы т.к. замена view - это всего лишь замена запроса и его плана, а не вставка новых данных куда-то, т.к. view в Посгресе совсем не materialized. А сам запрос по табличке конечно будет лучше выполняться с индексами. Кстати, ждем его EXPLAIN :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 20:29 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
угу... вот. Только он какой-от подозрительно маленький о_О Код: plaintext 1. 2. 3. 4. --- "Нефига себе у вас запросы!!!", сказала база данных и подохла... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 21:55 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
для выполнения запроса Код: plaintext 1. 2. 3. 4. 5. 6. 7. предлагаю попробовать Код: plaintext 1. 2. Код: plaintext 1. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 07:54 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
Ок, протестирую. Авот на счёт удаления всех остальных индексов - это принцыпиально? --- "Нефига себе у вас запросы!!!", сказала база данных и подохла... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 08:45 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
индексы нужны для сортировок, фильтров и джойнов. так? в вашем запросе есть фильтр выражению (создаем индекс) и сортировка по полю (создаем индекс). ответьте, для чего вам нужны остальные индексы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 09:20 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
darkfox Авот на счёт удаления всех остальных индексов - это принцыпиально? Для времени выполнения обсуждаемого запроса это не принципиально. Попробуйте убрать ORDER BY чтобы понять, на что, собственно, тратится время. И не использовать VIEW в тех же целях. Я не очень большой специалист по части анализа PostgreSQLных планов запросов, но слова HashAggregate и SubQuery кажутся мне подозрительными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 09:27 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
darkfox Что касается индексов, то они имеют смысл всегда, т.к. для сервера быстрее сделать выборку из него, нежели перебирать всю таблицу. тут у меня есть сомнения. например будет ли выражение like '%blabla%' использовать индекс? насколько я знаю нет. а юзать иногда надо. в оракле просто создаем максимально плотную таблицу, в результате поиск по выражению like '%blabla%' занимает доли секунды. Потом, если у вас используются агрегаты по довольно большим наборам данных, то, имхо, проще сразу уж делать seq scan по набору, а сами наборы выделить в партиции (к таблице все равно придеться обращаться за данными, а тут еще и в индекс надо лазить). Есть еще засада, например, когда вы покупаете хостинг для базы, где цена зависит от используемого места на диске. в этом случае создавать индексы "что б было" накладно Вобщем утверждение "всегда", на мой взгляд, не совсем верное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 10:22 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
ZemAиндексы нужны для сортировок, фильтров и джойнов. так? в вашем запросе есть фильтр выражению (создаем индекс) и сортировка по полю (создаем индекс). ответьте, для чего вам нужны остальные индексы?поюзать пару индексов в одном запросе - надо уметь. К тому ж, даже умеючи, - затратно. Т.ч. возможно имеет смысл иметь составные индексы. (не уверен, но к примеру по полям фильтра+поля группировки). самое главное - посмотреть, что будет после либо реиндекса, либо вакуума (индекс в ПГ при часто удаляемых записях, как поговаривают знатоки, может быть ох как раздут неактульными значениями - именно поэтому некоторые рекомендации звучат странно, я бы даже сказал - кощунственно... кстати, забавная иде я... могабыть вместо удаления сделать поле актуальности, а индекс сделать по WHERE actual = true ... как там поведет себя индекс - х.з., но выдавать указатели на не актуальные данные не должен - т.ч. обязан перестроиццо, а затем уже записи можно буит прибить). и имеет видимо смысл на триггерах поднять таблицу остатков. как текущих, так и на некие опорные даты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 10:43 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
У меня тоже оперативки 1.5, я думал, что умный, и держал shared_buffers = 70000 Случай показал, что shared_buffers = 10000 гораздо лучше. После ряда тестов пока остановился на 20000. Просто Linux очень неплохо сам кэширует диск. darkfoxНо хотелось бы решить проблему "в лоб", т.к. аналогичная задача на Оракле при тех же условиях работает в ДЕСЯТКИ раз быстрее. Oracle не зря ест свой хлеб... Если б только не мазал икру так жирно :-) Я постарался выкрутиться кэшированием: раз в пять минут выполняю агрегирующий запрос, его результаты сохраняю в табличке. Также сохраняю номер последней записи, попавшей в запрос. Затем online выборку делаю начиная с этой записи и плюсую её к сохранённой группировке. Работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 11:10 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
darkfoxугу... вот. Только он какой-от подозрительно маленький о_О Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 13:42 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
1. Прочитай про настройку шаред буферов для оракла (на сайте санок) и сделай как написано. 2. Используй битмап скан вместо индексскана (опцию в конфиге включить надо в 8.1, в 8.2 не знаю, может, по умолчанию) 3. Сравнивай элементы одного типа (а не дату с таймстемпом, приводить ВСЕ записи к дате плохая идея, приводи параметр запроса к таймстемпу, выигрыш при использовании индекса огромный) 4. Используй курсоры (пошли подальше тех, кто говорит, что курсоров в постгресе нет и прочитай наконец мануал) 5. Используй таймстемп без временной зоны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2007, 03:22 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
Ох уж ети праздники :( Так всётаки продолжу тему. С нового года таблицу с логами переименовал и вместо неё завёл чистую за 2007 год. поле timestamptz перевёл в timestamp (ну не нужна мне зона.) И что самое интересное тормоза в конструкции запроса по 10-20 минут!!! вот условия запроса: Код: plaintext 1. 2. заменил условие, как было предложено выше, на: Код: plaintext 1. и это без индексов. Я совершенно ничего не понимаю О_О ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2007, 10:33 |
|
||
|
PgSQL неохотно ест память. Статьи по оптимизации.
|
|||
|---|---|---|---|
|
#18+
darkfoxубил индексы интереса ради. Эффект тот же. заменил условие, как было предложено выше запрос летаит по 562ms O_O и это без индексов. Я совершенно ничего не понимаю О_Опоказывайте планы. explain analyze. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2007, 12:01 |
|
||
|
|

start [/forum/topic.php?fid=53&tid=2005748]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
7ms |
check topic access: |
7ms |
track hit: |
57ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
212ms |
get tp. blocked users: |
2ms |
| others: | 239ms |
| total: | 555ms |

| 0 / 0 |
