powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PgSQL неохотно ест память. Статьи по оптимизации.
25 сообщений из 50, страница 1 из 2
PgSQL неохотно ест память. Статьи по оптимизации.
    #34224550
darkfox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сервак: IBM E-Server 235 1.5 Гб оперативки.
Тормоза жуткие. Все манипуляции, описанные в рекомендациях произвёл. КПД почти 0.
Хотел поинтересоватсья. Может встречал кто статьи, посвящённые оптимизации работы сабжа, кроме переписок из мануала от PG???


---
"Нефига себе у вас запросы!!!", сказала база данных и подохла...
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34225094
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
darkfoxСервак: IBM E-Server 235 1.5 Гб оперативки.
Тормоза жуткие. Все манипуляции, описанные в рекомендациях произвёл. КПД почти 0.

А можно в этом месте поподробнее?
1. Версия PG?
2. Какие настройки?
3. Есть ли что-то еще на этой машине?
4. Тормоза на каких запросах? Каков объем данных?
5. А что с дисковой подсистемой?

darkfox
Хотел поинтересоватсья. Может встречал кто статьи, посвящённые оптимизации работы сабжа, кроме переписок из мануала от PG???

Ну, а там не так много парамтеров которые спецефичны для PG и которые можно крутить :)
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34225111
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну и еще желательно сказать какие манипуляции были сделаны. А то с телепатией не у всех хорошо :)
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34225452
ilejn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще хорошо бы узнать, какие задачи решает сервер.

У тебя, может быть, длинные, но редкие, запросы, у которых неудачно используется индекс, а мы тебе тут будем советовать чекпоинты почаще устраивать...
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34225869
darkfox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
упс, в порыве рабочего дня забыл про главное. Сорь. :)

Начну с конфига (postgresql.conf).
версия: postgres (PostgreSQL) 8.0.9 под Gentoo.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
max_connections =  100 

# - Memory -

shared_buffers =  100000          # min  16 , at least max_connections* 2 , 8KB each
work_mem =  1248576               # min  64 , size in KB
maintenance_work_mem =  163840    # min  1024 , size in KB
max_stack_depth =  2048           # min  100 , size in KB
sort_mem =  10240 
Остальные опции по дефолту.


Что касается основного бункера:
Классика для тестирования больших запросов - лог 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.
CREATE TABLE "traffic"."squidlog" (
  "dt" TIMESTAMP WITH TIME ZONE NOT NULL, 
  "replytime" NUMERIC( 10 , 0 ), 
  "dip" VARCHAR( 15 ) NOT NULL, 
  "r_mnemo" VARCHAR( 128 ), 
  "r_code" NUMERIC( 3 , 0 ), 
  "bytes" NUMERIC( 12 , 0 ) NOT NULL, 
  "method" VARCHAR( 12 ), 
  "url" TEXT NOT NULL, 
  "login" VARCHAR( 128 ) NOT NULL, 
  "connect" VARCHAR( 64 ), 
  "mimetype" VARCHAR( 100 ), 
  "surl" VARCHAR( 254 ), 
  "unixdt" NUMERIC( 14 , 3 )
) WITH OIDS;

CREATE INDEX "squidlog_bytes" ON "traffic"."squidlog"
  USING btree ("bytes");

CREATE INDEX "squidlog_connect" ON "traffic"."squidlog"
  USING btree ("connect");

CREATE INDEX "squidlog_dip" ON "traffic"."squidlog"
  USING btree ("dip");

CREATE INDEX "squidlog_dt" ON "traffic"."squidlog"
  USING btree ("dt");

CREATE INDEX "squidlog_login" ON "traffic"."squidlog"
  USING btree ("login");

CREATE INDEX "squidlog_method" ON "traffic"."squidlog"
  USING btree ("method");

CREATE INDEX "squidlog_mimetype" ON "traffic"."squidlog"
  USING btree ("mimetype");

CREATE INDEX "squidlog_rcode" ON "traffic"."squidlog"
  USING btree ("r_code");

CREATE INDEX "squidlog_rmnemo" ON "traffic"."squidlog"
  USING btree ("r_mnemo");

CREATE INDEX "squidlog_surl" ON "traffic"."squidlog"
  USING btree ("surl");

CREATE INDEX "squidlog_unixdt" ON "traffic"."squidlog"
  USING btree ("unixdt");
на момент написания поста count(*) составлял 23843712

Дабы сильно не насиловать основной бункер, имеется View, отражающий текущий лог за месяц:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
REATE OR REPLACE VIEW "traffic"."curr_squidlog" (
    dt,
    replytime,
    dip,
    r_mnemo,
    r_code,
    bytes,
    method,
    url,
    login,
    connect,
    mimetype,
    surl,
    unixdt)
AS
SELECT squidlog.dt, squidlog.replytime, squidlog.dip, squidlog.r_mnemo,
    squidlog.r_code, squidlog.bytes, squidlog.method, squidlog.url,
    squidlog.login, squidlog.connect, squidlog.mimetype, squidlog.surl, squidlog.unixdt
FROM traffic.squidlog
WHERE ((squidlog.dt >= date_trunc('month'::text, now())) AND (squidlog.dt <
    (date_trunc('month'::text, now()) + '1 mon'::interval)))
ORDER BY squidlog.dt;

нижеприведённый запрос уходит в себя на 48сек. +-10 :) А если соединить это с таблицей users по полю login(не больше 300 записей), то время вырастает ещё больше
Код: plaintext
1.
select tsl.login, tsl.surl, sum(bytes) from traffic.curr_squidlog tsl
group by login, surl



---
"Нефига себе у вас запросы!!!", сказала база данных и подохла...
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34225897
alex_v13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ну а что explain говорит-то на этот запрос?

И work_mem = 1248576 - это больше гига и вряд ли поможет, все равно в кэш уйдет..
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34225905
alex_v13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PS: то же касается и share_buffers - больше 10 000...15 000 на машинах с 1.5 ГБ ставить не имеет смысла, а у Вас 100 000 -это не описка?
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34225959
st_serg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
если в squidlog часто и густо вставляются записи, то смысл кучи индексов на ней? имхо лучше запускать какойнить джоб, для предварительного агрегирования данных. на больших таблицах может иметь смысл партицирование
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226141
darkfox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
На серваке 1.5Гб оперативки.
2Alex_v13: 100000 не описка. я так понял, что это объём разделяемой памяти, используемой сервером. Соответственно 100000*8=800000
800000/1024=781Мб
нет? ;\

Что касается индексов, то они имеют смысл всегда, т.к. для сервера быстрее сделать выборку из него, нежели перебирать всю таблицу. (другое дело, что у ПГ с ними трабла. Один тип вообще не рекомендуют использовать, другой и цепляется не всегда.)

Что касается разукрупнения бункера(сводные таблицы и тп.), то с этим и так всё ясно. Но хотелось бы решить проблему "в лоб", т.к. аналогичная задача на Оракле при тех же условиях работает в ДЕСЯТКИ раз быстрее.
Но уж на крайний случай единственное разумное решение вижу, чтобы поля URL и sURL вынести в отдельную таблицу, и тоже скажу про классификационные величины (method, mimetype)

Однако делать не хочется ещё и по тому, что была задача аналогичная(технически) с товарооборотом компании. В ней 30млн уникальных позиций (в год) по оборотам. Данные из которых получают в режиме реального времени.

Вобщем пока ещё раз делаю вывод, что FSF базы не готовы к большим объёмам данных. Печально.
Но буду рад, если переубедит кто или ткнёт носом в ошибки и правильное решение.

---
"Нефига себе у вас запросы!!!", сказала база данных и подохла...
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226152
wbear
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
помойму запрос остается запросом во вюшке он или нет.. выиграша там помойму 0.
или в посгря уже научилась вюшки быстрее запросов на таблицу выполнять?? :0

(почему-то большинство манагеров думают что ВСЕГДА код дороже оптимизить чем покупать новое жалезо...и настраивать софт.)

и я тоже посоветую индексы нафих убить. , переделал на вставку данных пачками через copy(ну не посекундная же у вас тарификация а если хотите рубить конекты и отрубать пользователей по достижению лимита трафика то видимо всеравно пока вы сквиду будете об этом сообщять уйдет какое-то время т.е. превышение будет.. мне кажется надо это принять как должное и уже спокойно давать ему еще 15 минут покачать прнуху -угадал? :)
и отдельно агрегировать + видимо имеет смысл побить таблицу squidlog например по месяцам.

еще мона тригер повесить на инсерт в эту таблицу типа
trigger on insert on squid_log
update login_traf set traf=traf+NEW.traf where login=NEW.login...

т.е. агрегируем на лету..
юзеров видимо не мильен.. так. что что особо не нагрузит вставку.

ну как-то так..
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226164
wbear
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Что касается индексов, то они имеют смысл всегда, т.к. для сервера быстрее сделать выборку из него, нежели перебирать всю таблицу.

только не в случае когда у вас обновление и вставка в таблицу на несколько порядков больше чем чтение -тут стоит задуматся. перестройка индексов тоже нехилая операция. и посмотрите сколько занимают все ваши индексы по сравнению с самой таблицей(в килобайтах).
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226225
darkfox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
вьюшки в ПГ медленнее обычного запроса!??! Убить индексы на таблицы?!?!? О_О
сколько я помню, так индексы делались для ускорения поиска и запросов по таблице...
или вы хотите сказать, что в ПГ индексы-дурной тон?! О_О

И потом, индексы пополняются при вставке, а не перестраиваются... кажется(теперь я уже не уверен)

Вобщем пока тихий УЖОС!!!
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226253
alex_v13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ну я не вижу собственно вляния индесов на обновление базы т.к. замена view - это всего лишь замена запроса и его плана, а не вставка новых данных куда-то, т.к. view в Посгресе совсем не materialized. А сам запрос по табличке конечно будет лучше выполняться с индексами.
Кстати, ждем его EXPLAIN :)
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226388
darkfox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
угу... вот. Только он какой-от подозрительно маленький о_О

Код: plaintext
1.
2.
3.
4.
QUERY PLAN
HashAggregate  (cost= 3 . 05 .. 3 . 05  rows= 1  width= 241 )
  ->  Subquery Scan curr_squidlog  (cost= 0 . 01 .. 3 . 04  rows= 1  width= 241 )
        ->  Index Scan using squidlog_dt on squidlog  (cost= 0 . 01 .. 3 . 03  rows= 1  width= 196 )
              Index Cond: ((dt >= date_trunc('month'::text, now())) AND (dt < (date_trunc('month'::text, now()) + '1 mon'::interval)))


---
"Нефига себе у вас запросы!!!", сказала база данных и подохла...
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226660
ZemA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
для выполнения запроса
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT squidlog.dt, squidlog.replytime, squidlog.dip, squidlog.r_mnemo,
    squidlog.r_code, squidlog.bytes, squidlog.method, squidlog.url,
    squidlog.login, squidlog.connect, squidlog.mimetype, squidlog.surl, squidlog.unixdt
FROM traffic.squidlog
WHERE ((squidlog.dt >= date_trunc('month'::text, now())) AND (squidlog.dt <
    (date_trunc('month'::text, now()) + '1 mon'::interval)))
ORDER BY squidlog.dt;
вам не нужно столько индексов.

предлагаю попробовать
Код: plaintext
1.
2.
WHERE ((squidlog.dt >= date_trunc('month'::text, now())) AND (squidlog.dt <
    (date_trunc('month'::text, now()) + '1 mon'::interval)))
заменить на
Код: plaintext
1.
WHERE date_part('month', dt) = date_part('month', now())
и создать индекс
Код: plaintext
1.
create index squidlog_by_month on traffic.squidlog (date_part('month', dt))
остальные индексы удалить.
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226712
darkfox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ок, протестирую.
Авот на счёт удаления всех остальных индексов - это принцыпиально?




---
"Нефига себе у вас запросы!!!", сказала база данных и подохла...
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226787
ZemA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
индексы нужны для сортировок, фильтров и джойнов. так?
в вашем запросе есть фильтр выражению (создаем индекс) и сортировка по полю (создаем индекс).
ответьте, для чего вам нужны остальные индексы?
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226805
ilejn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
darkfox
Авот на счёт удаления всех остальных индексов - это принцыпиально?


Для времени выполнения обсуждаемого запроса это не принципиально.


Попробуйте убрать ORDER BY чтобы понять, на что, собственно, тратится время.
И не использовать VIEW в тех же целях.

Я не очень большой специалист по части анализа PostgreSQLных планов запросов,
но слова HashAggregate и SubQuery кажутся мне подозрительными.
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34226956
st_serg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
darkfox
Что касается индексов, то они имеют смысл всегда, т.к. для сервера быстрее сделать выборку из него, нежели перебирать всю таблицу.
тут у меня есть сомнения. например будет ли выражение like '%blabla%' использовать индекс? насколько я знаю нет. а юзать иногда надо. в оракле просто создаем максимально плотную таблицу, в результате поиск по выражению like '%blabla%' занимает доли секунды. Потом, если у вас используются агрегаты по довольно большим наборам данных, то, имхо, проще сразу уж делать seq scan по набору, а сами наборы выделить в партиции (к таблице все равно придеться обращаться за данными, а тут еще и в индекс надо лазить). Есть еще засада, например, когда вы покупаете хостинг для базы, где цена зависит от используемого места на диске. в этом случае создавать индексы "что б было" накладно
Вобщем утверждение "всегда", на мой взгляд, не совсем верное.
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34227039
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZemAиндексы нужны для сортировок, фильтров и джойнов. так?
в вашем запросе есть фильтр выражению (создаем индекс) и сортировка по полю (создаем индекс).
ответьте, для чего вам нужны остальные индексы?поюзать пару индексов в одном запросе - надо уметь. К тому ж, даже умеючи, - затратно. Т.ч. возможно имеет смысл иметь составные индексы. (не уверен, но к примеру по полям фильтра+поля группировки).

самое главное - посмотреть, что будет после либо реиндекса, либо вакуума (индекс в ПГ при часто удаляемых записях, как поговаривают знатоки, может быть ох как раздут неактульными значениями - именно поэтому некоторые рекомендации звучат странно, я бы даже сказал - кощунственно... кстати, забавная иде я... могабыть вместо удаления сделать поле актуальности, а индекс сделать по WHERE actual = true ... как там поведет себя индекс - х.з., но выдавать указатели на не актуальные данные не должен - т.ч. обязан перестроиццо, а затем уже записи можно буит прибить).

и имеет видимо смысл на триггерах поднять таблицу остатков. как текущих, так и на некие опорные даты.
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34227150
Funny_Falcon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня тоже оперативки 1.5, я думал, что умный, и держал shared_buffers = 70000
Случай показал, что shared_buffers = 10000 гораздо лучше.
После ряда тестов пока остановился на 20000.

Просто Linux очень неплохо сам кэширует диск.

darkfoxНо хотелось бы решить проблему "в лоб", т.к. аналогичная задача на Оракле при тех же условиях работает в ДЕСЯТКИ раз быстрее.
Oracle не зря ест свой хлеб... Если б только не мазал икру так жирно :-)

Я постарался выкрутиться кэшированием: раз в пять минут выполняю агрегирующий запрос, его результаты сохраняю в табличке. Также сохраняю номер последней записи, попавшей в запрос.
Затем online выборку делаю начиная с этой записи и плюсую её к сохранённой группировке. Работает.
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34227830
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
darkfoxугу... вот. Только он какой-от подозрительно маленький о_О
Код: plaintext
1.
2.
3.
4.
QUERY PLAN
HashAggregate  (cost=3.05..3.05 rows=1 width=241)
  ->  Subquery Scan curr_squidlog  (cost=0.01..3.04 rows=1 width=241)
        ->  Index Scan using squidlog_dt on squidlog  (cost=0.01..3.03 rows=1 width=196)
              Index Cond: ((dt >= date_trunc('month'::text, now())) AND (dt < (date_trunc('month'::text, now()) + '1 mon'::interval)))
Выполните "vacuum analyze", чтобы планировшик не лажался при прогнозировании кол-ва строк. И приведите выдачу EXPLAIN ANALYZE.
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34254558
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
1. Прочитай про настройку шаред буферов для оракла (на сайте санок) и сделай как написано.
2. Используй битмап скан вместо индексскана (опцию в конфиге включить надо в 8.1, в 8.2 не знаю, может, по умолчанию)
3. Сравнивай элементы одного типа (а не дату с таймстемпом, приводить ВСЕ записи к дате плохая идея, приводи параметр запроса к таймстемпу, выигрыш при использовании индекса огромный)
4. Используй курсоры (пошли подальше тех, кто говорит, что курсоров в постгресе нет и прочитай наконец мануал)
5. Используй таймстемп без временной зоны
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34280961
darkfox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ох уж ети праздники :(
Так всётаки продолжу тему.
С нового года таблицу с логами переименовал и вместо неё завёл чистую за 2007 год.
поле timestamptz перевёл в timestamp (ну не нужна мне зона.)
И что самое интересное тормоза в конструкции запроса по 10-20 минут!!!
вот условия запроса:
Код: plaintext
1.
2.
WHERE ((squidlog.dt >= date_trunc('month'::text, now())) AND (squidlog.dt <
    (date_trunc('month'::text, now()) + '1 mon'::interval)))
убил индексы интереса ради. Эффект тот же.

заменил условие, как было предложено выше, на:
Код: plaintext
1.
WHERE date_part('month', dt) = date_part('month', now())
запрос летаит по 562ms O_O
и это без индексов.

Я совершенно ничего не понимаю О_О
...
Рейтинг: 0 / 0
PgSQL неохотно ест память. Статьи по оптимизации.
    #34281395
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
darkfoxубил индексы интереса ради. Эффект тот же.

заменил условие, как было предложено выше

запрос летаит по 562ms O_O и это без индексов.

Я совершенно ничего не понимаю О_Опоказывайте планы. explain analyze.
...
Рейтинг: 0 / 0
25 сообщений из 50, страница 1 из 2
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PgSQL неохотно ест память. Статьи по оптимизации.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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