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


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

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

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

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

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

Начну с конфига (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
26.12.2006, 17:32
    #34225897
alex_v13
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQL неохотно ест память. Статьи по оптимизации.
Ну а что explain говорит-то на этот запрос?

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

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

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

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

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

---
"Нефига себе у вас запросы!!!", сказала база данных и подохла...
...
Рейтинг: 0 / 0
26.12.2006, 19:25
    #34226152
wbear
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQL неохотно ест память. Статьи по оптимизации.
помойму запрос остается запросом во вюшке он или нет.. выиграша там помойму 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
26.12.2006, 19:30
    #34226164
wbear
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQL неохотно ест память. Статьи по оптимизации.
>Что касается индексов, то они имеют смысл всегда, т.к. для сервера быстрее сделать выборку из него, нежели перебирать всю таблицу.

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

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

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

Код: 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
27.12.2006, 07:54
    #34226660
ZemA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQL неохотно ест память. Статьи по оптимизации.
для выполнения запроса
Код: 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
27.12.2006, 08:45
    #34226712
darkfox
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQL неохотно ест память. Статьи по оптимизации.
Ок, протестирую.
Авот на счёт удаления всех остальных индексов - это принцыпиально?




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


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


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

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

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

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

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

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

Я постарался выкрутиться кэшированием: раз в пять минут выполняю агрегирующий запрос, его результаты сохраняю в табличке. Также сохраняю номер последней записи, попавшей в запрос.
Затем online выборку делаю начиная с этой записи и плюсую её к сохранённой группировке. Работает.
...
Рейтинг: 0 / 0
27.12.2006, 13:42
    #34227830
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQL неохотно ест память. Статьи по оптимизации.
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
15.01.2007, 03:22
    #34254558
MBG
MBG
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQL неохотно ест память. Статьи по оптимизации.
1. Прочитай про настройку шаред буферов для оракла (на сайте санок) и сделай как написано.
2. Используй битмап скан вместо индексскана (опцию в конфиге включить надо в 8.1, в 8.2 не знаю, может, по умолчанию)
3. Сравнивай элементы одного типа (а не дату с таймстемпом, приводить ВСЕ записи к дате плохая идея, приводи параметр запроса к таймстемпу, выигрыш при использовании индекса огромный)
4. Используй курсоры (пошли подальше тех, кто говорит, что курсоров в постгресе нет и прочитай наконец мануал)
5. Используй таймстемп без временной зоны
...
Рейтинг: 0 / 0
25.01.2007, 10:33
    #34280961
darkfox
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQL неохотно ест память. Статьи по оптимизации.
Ох уж ети праздники :(
Так всётаки продолжу тему.
С нового года таблицу с логами переименовал и вместо неё завёл чистую за 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
25.01.2007, 12:01
    #34281395
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQL неохотно ест память. Статьи по оптимизации.
darkfoxубил индексы интереса ради. Эффект тот же.

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

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

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


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