powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / стало очень медленно
12 сообщений из 12, страница 1 из 1
стало очень медленно
    #34549097
IgoX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем привет
pgsql 7
AltLinux 2.4
[root@tank root]# cat /proc/cpu
cpufreq cpuinfo
[root@tank root]# cat /proc/cpuinfo
...
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
...
Вот ТОР
CPU states: 19.4% user, 70.4% system, 0.0% nice, 0.0% iowait, 10.1% idle
Mem: 506044k av, 500804k used, 5240k free, 0k shrd, 2428k buff
215028k active, 256416k inactive
Swap: 1044184k av, 3660k used, 1040524k free 450340k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
12246 postgres 19 0 11456 11M 10824 R 67.1 2.2 1:07 postmaster
---------------------------------
есть таблица all_traf, в ней поле timestamp и индекс по нему.
в таблице записей не очень много около 5млн.
раньше запрос
Код: plaintext
select sum(bytes) from all_traf where timestamp<='2007-05-24 23:59:59' and timestamp>='2007-05-01 00:00:01';
отрабатывал меньше чем за 30 сек(т.к. РНР по умолчанию только 30 сек висит). Потом база выросла до 9млн и началось. Я перенес устаревшие данные в др. таблицу стало около 5млн, после чего делал и vacuum full и vacuum analyze all_tarf и cluster index и перегружал postgresql, но результат плохой,
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
explain analyze select sum(bytes) from all_traf where timestamp<='2007-05-24 23:59:59' and timestamp>='2007-05-01 00:00:01';
                                                                            QUERY PLAN                                             
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost= 115858 . 02 .. 115858 . 02  rows= 1  width= 8 ) (actual time= 189338 . 113 .. 189338 . 113  rows= 1  loops= 1 )
   ->  Index Scan using i_timestamp on all_traf  (cost= 0 . 00 .. 108511 . 26  rows= 2938704  width= 8 ) (actual time= 34 . 757 .. 155593 . 464  rows= 3178388  loops= 1 )
         Index Cond: (("timestamp" <= '2007-05-24 23:59:59'::timestamp without time zone) AND ("timestamp" >= '2007-05-01 00:00:01'::timestamp without time zone))
 Total runtime:  189359 . 860  ms
Реально что нибудь подкрутить?
...
Рейтинг: 0 / 0
стало очень медленно
    #34549248
СергейК
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
IgoXВсем привет
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
explain analyze select sum(bytes) from all_traf where timestamp<='2007-05-24 23:59:59' and timestamp>='2007-05-01 00:00:01';
                                                                            QUERY PLAN                                             
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost= 115858 . 02 .. 115858 . 02  rows= 1  width= 8 ) (actual time= 189338 . 113 .. 189338 . 113  rows= 1  loops= 1 )
   ->  Index Scan using i_timestamp on all_traf  (cost= 0 . 00 .. 108511 . 26  rows= 2938704  width= 8 ) (actual time= 34 . 757 .. 155593 . 464  rows= 3178388  loops= 1 )
         Index Cond: (("timestamp" <= '2007-05-24 23:59:59'::timestamp without time zone) AND ("timestamp" >= '2007-05-01 00:00:01'::timestamp without time zone))
 Total runtime:  189359 . 860  ms
Реально что нибудь подкрутить?

A poprobuite, sdelat'
set enable_indexscan to off;
i zapustite zapros. Potomu chto ia viju, chto v vashem zaprose index' scan'om prohoditsia 3 milliona zapisei (tret' tablitsy), i v takom sluchae prostoi seqscan mojet byt' i bystree..

I voobshe ia by posovetoval vse-taki obnovit' PG s 7-ki (vy ne napisali kakoi) na chto-nibud' bolee novoe (8.2 naprimer)(tam izmenenii kasaushisia index scan'ov i aggregatov nakopilos' ochen' mnogo)...
...
Рейтинг: 0 / 0
стало очень медленно
    #34549254
domanix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Похоже слишком много данных удовлетворяет условию.
А что измениться если это же запрос запустить без использования индексов?
...
Рейтинг: 0 / 0
стало очень медленно
    #34549320
IgoX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
internet=# set enable_indexscan TO off;
SET
internet=# explain analyze select sum(bytes) from all_traf where timestamp<='2007-05-24 23:59:59' and timestamp>='2007-05-01 00:00:01';
                                                                          QUERY PLAN                                               
---------------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost= 182376 . 54 .. 182376 . 54  rows= 1  width= 8 ) (actual time= 296314 . 182 .. 296314 . 183  rows= 1  loops= 1 )
   ->  Seq Scan on all_traf  (cost= 0 . 00 .. 175029 . 78  rows= 2938704  width= 8 ) (actual time= 121758 . 192 .. 258604 . 541  rows= 3178388  loops= 1 )
         Filter: (("timestamp" <= '2007-05-24 23:59:59'::timestamp without time zone) AND ("timestamp" >= '2007-05-01 00:00:01'::timestamp without time zone))
 Total runtime:  296314 . 225  ms
...
Рейтинг: 0 / 0
стало очень медленно
    #34549371
IgoX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
на счет 8 подумаю, но на это надо время. а вот может что с query tuning надо сделать уменя там всё поумолчанию, хотя мои изменения совсем не дали результатов.

tcpip_socket = true
max_connections = 100
virtual_host = '127.0.0.1' # what interface to listen on; defaults to any
shared_buffers = 3000 # min 16, at least max_connections*2, 8KB each
sort_mem = 9024 # min 64, size in KB
syslog = 2 # range 0-2; 0=stdout; 1=both; 2=syslog
log_min_duration_statement = -1 # Log all statements whose
silent_mode = false # DO NOT USE without Syslog!
log_connections = false
lc_messages = 'ru_RU.KOI8-R' # locale for system error message strings
lc_monetary = 'ru_RU.KOI8-R' # locale for monetary formatting
lc_numeric = 'ru_RU.KOI8-R' # locale for number formatting
lc_time = 'ru_RU.KOI8-R' # locale for time formatting

и странное что если shared_buffers ставлю 4000 и больше то сервис не загружается
...
Рейтинг: 0 / 0
стало очень медленно
    #34549402
st_serg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgoX
...
и странное что если shared_buffers ставлю 4000 и больше то сервис не загружается
16.4. Managing Kernel Resources
...
Рейтинг: 0 / 0
стало очень медленно
    #34549584
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
5 000 000 (строк) * 8 b (width) = 40 Mb
3 000 (shared_buffers) * 8 Kb = 24 Mb

не хватает. увеличивайте shared_buffers.
...
Рейтинг: 0 / 0
стало очень медленно
    #34550460
IgoX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
за ночь добавилось 400 тыс.строк результат выборки Total runtime: 255523.802 ms
потом я увеличил shmmax и сделал shured_buffers=10000
Вот ТОР
Mem: 506044k av, 501764k used, 4280k free, 0k shrd, 2896k buff
26076k active, 444496k inactive
Swap: 1044184k av, 3656k used, 1040528k free 420656k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
21985 postgres 20 0 84476 82M 83780 R 55.6 16.6 2:45 postmaster
но после увеличения, время как показывалось так и показывается, хотя памяти ест намного больше
Total runtime: 255698.250 ms
увеличил sort_mem=51200 или он влияет на INSERT и CREATE INDEX правильно?(не очень с анг. языком дружу )
Total runtime: 255767.184 ms
и зачем тогда он ест больше памяти а скорость та же ???
может помимо shured_buffer и sort_mem еще надо покрутить
...
Рейтинг: 0 / 0
стало очень медленно
    #34550501
Kruchinin Pahan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgoX
и зачем тогда он ест больше памяти а скорость та же ???
может помимо shured_buffer и sort_mem еще надо покрутить
Может, я скажу какую-нибудь глупость. Но иногда после изменений настроек полезно сделать VACUUM ANALYZE FULL.
...
Рейтинг: 0 / 0
стало очень медленно
    #34551430
IgoX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
логикой непойму, почему после увиличения делать vacuum, но он не помог
...
Рейтинг: 0 / 0
стало очень медленно
    #34551468
СергейК
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Tak kak u vas pg 7.xx, to, naskolko ia ponimau, mojete poprobovat' sdelat' reindex vashego index'a...
(sm. zdes' )

I eshe vopros, mnogo li u vas kolonok, i skolko voobshe tablitsa zanimaet... I kakuiu skorost' chtenia ukazyvaet vmstat, i kak silno CPU zaniat (kak vo vremia seq. scana i index scana).
I eshe. Pri povtorenii zaprosa, naskolko meniaetsia vremia ispolnenia ?
...
Рейтинг: 0 / 0
стало очень медленно
    #34553012
Kruchinin Pahan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgoXлогикой непойму, почему после увиличения делать vacuum, но он не помог
Объясняю, планировщик сохраняет данные о фрагментации таблиц, индексов, наиболее часто используемых значений и т.д. и т.п. иногда сделать ANALYZE после изменения настроек оказывается полезным.
...
Рейтинг: 0 / 0
12 сообщений из 12, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / стало очень медленно
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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