ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Большая база на медленной "машине"
12 сообщений из 12, страница 1 из 1
Большая база на медленной "машине"
    #34867466
Ivan A.Zhukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan A.Zhukov
Гость
Подскажите как можно оптимизировать работу с базой (9 полей, более 10 милионов записей в год) на достаточно слабенькой "машинке" (P255, 128mb(оперативки),40gb(винт)). Стоит FreeBSD 6.0 и PGSQL 7.4.13. Использую в основном команды SELECT в том числе вложеные (делаеться очень медленно), в базу запись происходит раз в сутки (не критично). При запросах типа (SELECT * FROM table WHERE date >'начало' AND date >'конец';) работает ОЧЕНЬ долго (минут по 15).Пробовал сделать индексы помогло не очень. Потом разбил на 12 таблиц (по месяцам) стало побыстрее, но хочеться еще ускорить.
Подскажите что еще можно "покрутить" для ускорения (или где почитать, желательно по русски)?
...
Рейтинг: 0 / 0
14.10.2007, 19:15
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34867617
Oleg Bartunov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Oleg Bartunov
Участник
Ivan A.ZhukovПодскажите как можно оптимизировать работу с базой (9 полей, более 10 милионов записей в год) на достаточно слабенькой "машинке" (P255, 128mb(оперативки),40gb(винт)). Стоит FreeBSD 6.0 и PGSQL 7.4.13. Использую в основном команды SELECT в том числе вложеные (делаеться очень медленно), в базу запись происходит раз в сутки (не критично). При запросах типа (SELECT * FROM table WHERE date >'начало' AND date >'конец';) работает ОЧЕНЬ долго (минут по 15).Пробовал сделать индексы помогло не очень. Потом разбил на 12 таблиц (по месяцам) стало побыстрее, но хочеться еще ускорить.
Подскажите что еще можно "покрутить" для ускорения (или где почитать, желательно по русски)?

* Поставить 8.2.5
* Потюнить postgresql.conf
* Использовать partition + constraint exclusion
* Индексы
* Показать explain analyze
...
Рейтинг: 0 / 0
14.10.2007, 22:14
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34868058
Winnipuh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Winnipuh
Участник
Oleg Bartunov Ivan A.ZhukovПодскажите как можно оптимизировать работу с базой (9 полей, более 10 милионов записей в год) на достаточно слабенькой "машинке" (P255, 128mb(оперативки),40gb(винт)). Стоит FreeBSD 6.0 и PGSQL 7.4.13. Использую в основном команды SELECT в том числе вложеные (делаеться очень медленно), в базу запись происходит раз в сутки (не критично). При запросах типа (SELECT * FROM table WHERE date >'начало' AND date >'конец';) работает ОЧЕНЬ долго (минут по 15).Пробовал сделать индексы помогло не очень. Потом разбил на 12 таблиц (по месяцам) стало побыстрее, но хочеться еще ускорить.
Подскажите что еще можно "покрутить" для ускорения (или где почитать, желательно по русски)?

* Поставить 8.2.5
* Потюнить postgresql.conf
* Использовать partition + constraint exclusion
* Индексы
* Показать explain analyze

а почему не 8.3? ;)
...
Рейтинг: 0 / 0
15.10.2007, 10:29
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34869359
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
Winnipuh
а почему не 8.3? ;)
8.3 еще не продакшен. Поэтому советовать ее для боевой базы неосмотрительно. Она предназначена для тестирования.
...
Рейтинг: 0 / 0
15.10.2007, 15:40
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34869935
Ivan A.Zhukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan A.Zhukov
Гость
Oleg Bartunov* Поставить 8.2.5
А она быстрее будет на такой медленной машине?
Oleg Bartunov* Потюнить postgresql.conf
А где про это, по русски, можно почитать?
Oleg Bartunov* Использовать partition + constraint exclusion
А это что за зверь? (по русски желательно) :-)
Oleg Bartunov* Индексы
Дак делаю я их. Вот только не знаю лучше на каждое поле по одному или один на все поля? В запросах в секции WHERE фигурирует три, четыре поля.
Oleg Bartunov* Показать explain analyze
Выдает ошибку. :-(
Код: plaintext
1.
statistic=# explain analyze;
ERROR:  syntax error at or near ";" at character  16
...
Рейтинг: 0 / 0
15.10.2007, 18:03
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34870012
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
Ivan A.Zhukov Oleg Bartunov* Поставить 8.2.5
А она быстрее будет на такой медленной машине?
Oleg Bartunov* Потюнить postgresql.conf
А где про это, по русски, можно почитать?
Oleg Bartunov* Использовать partition + constraint exclusion
А это что за зверь? (по русски желательно) :-)
Oleg Bartunov* Индексы
Дак делаю я их. Вот только не знаю лучше на каждое поле по одному или один на все поля? В запросах в секции WHERE фигурирует три, четыре поля.
Oleg Bartunov* Показать explain analyze
Выдает ошибку. :-(
Код: plaintext
1.
statistic=# explain analyze;
ERROR:  syntax error at or near ";" at character  16

1. Она в принципе - быстрее. По идее и на такой машине тоже. Может быть нужно немного памяти добросить для ускорения запросов.
2. В ФАК.
3. В доки (на русском не думаю что что-то будет серьезное) + поиск по форуму.
4. explain analyze SELECT .... ; где SELECT ... - это Ваш тормозящий мегазапрос. Поищите по форуму.
...
Рейтинг: 0 / 0
15.10.2007, 18:28
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34870074
Ivan A.Zhukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan A.Zhukov
Гость
Понял, поищу.
...
Рейтинг: 0 / 0
15.10.2007, 18:55
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34870119
Ivan A.Zhukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan A.Zhukov
Гость
Andrey Daeron4. explain analyze SELECT .... ; где SELECT ... - это Ваш тормозящий мегазапрос. Поищите по форуму.
Вот ответ на самый простой запрос. О чем он может сказать? Подскажите, пожалуйста.

statistic=# explain analyze SELECT src_addr FROM tmp2_2007_09 WHERE src_addr <<
'192.168.101/24' GROUP BY src_addr ORDER BY src_addr;
QUERY PLAN

--------------------------------------------------------------------------------
----------------------------------------------------
Sort (cost=5837.99..5838.53 rows=214 width=11) (actual time=8892.798..8892.818
rows=5 loops=1)
Sort Key: src_addr
-> HashAggregate (cost=5829.71..5829.71 rows=214 width=11) (actual time=889
2.583..8892.659 rows=5 loops=1)
-> Seq Scan on tmp2_2007_09 (cost=0.00..5526.83 rows=121153 width=11)
(actual time=362.747..7710.932 rows=48437 loops=1)
Filter: (src_addr << '192.168.101.0/24'::inet)
Total runtime: 8893.659 ms
(записей: 6)
...
Рейтинг: 0 / 0
15.10.2007, 19:13
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34870153
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
Ivan A.Zhukov Andrey Daeron4. explain analyze SELECT .... ; где SELECT ... - это Ваш тормозящий мегазапрос. Поищите по форуму.
Вот ответ на самый простой запрос. О чем он может сказать? Подскажите, пожалуйста.

statistic=# explain analyze SELECT src_addr FROM tmp2_2007_09 WHERE src_addr <<
'192.168.101/24' GROUP BY src_addr ORDER BY src_addr;
QUERY PLAN

--------------------------------------------------------------------------------
----------------------------------------------------
Sort (cost=5837.99..5838.53 rows=214 width=11) (actual time=8892.798..8892.818
rows=5 loops=1)
Sort Key: src_addr
-> HashAggregate (cost=5829.71..5829.71 rows=214 width=11) (actual time=889
2.583..8892.659 rows=5 loops=1)
-> Seq Scan on tmp2_2007_09 (cost=0.00..5526.83 rows=121153 width=11)
(actual time=362.747..7710.932 rows=48437 loops=1)
Filter: (src_addr << '192.168.101.0/24'::inet)
Total runtime: 8893.659 ms
(записей: 6)
1. Индекса по src_addr или нет, или не используется (в связи с этим рекомендация перейти на 8.2 еще более актуальна, до 8-ки несоответсвие типов приводила к неиспользвоанию индексов, т.е. нужно приведение типов вручную). + не уверен, что по типу INET для операции << PostgreSQL может использовать индекс. Это может кто-то более компетентный подскажет.
2. Планер "некисло" ошибается при оценке кол-ва строк: ждет 121153, а получает 48437. Возможно давно делалася VACUUM FULL ANALYZE (точнее ANALYZE, но тем не менее).
3. Основное время тратится на полное чтение таблицы. 362.747..7710.932.
...
Рейтинг: 0 / 0
15.10.2007, 19:33
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34870181
Ivan A.Zhukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan A.Zhukov
Гость
Andrey Daeron1. Индекса по src_addr или нет, или не используется (в связи с этим рекомендация перейти на 8.2 еще более актуальна, до 8-ки несоответсвие типов приводила к неиспользвоанию индексов, т.е. нужно приведение типов вручную). + не уверен, что по типу INET для операции << PostgreSQL может использовать индекс. Это может кто-то более компетентный подскажет.
2. Планер "некисло" ошибается при оценке кол-ва строк: ждет 121153, а получает 48437. Возможно давно делалася VACUUM FULL ANALYZE (точнее ANALYZE, но тем не менее).
3. Основное время тратится на полное чтение таблицы. 362.747..7710.932.
1. Понял буду работать в этом направлении.
2. VACUUM FULL ANALYZE делал сегодня.
3. А что сделать чтобы это время уменьшить?
...
Рейтинг: 0 / 0
15.10.2007, 19:54
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34870199
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
Ivan A.Zhukov
1. Понял буду работать в этом направлении.
2. VACUUM FULL ANALYZE делал сегодня.
3. А что сделать чтобы это время уменьшить?
1. :) тесты бы поделать
2. Значит попробуйте поднять статистику по этому полю.
3. Ну тут уже скорее всего проблемы аппаратной части. Славно было бы перейти на использование индексов, что бы не все читать. Кста, а сколько у Вас в принципе данных в таблице?
Можно еще поиграться с отключением/включением принудительного неиспользования seq_scan.
...
Рейтинг: 0 / 0
15.10.2007, 20:05
| Ответить | Цитировать | Написать  
Большая база на медленной "машине"
    #34870871
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Ivan A.ZhukovВот ответ на самый простой запрос. О чем он может сказать? Подскажите, пожалуйста.

-> HashAggregate (actual rows=5)
-> Seq Scan (actual rows=48437)для distinct выборки пяти строк приходится прочесать пятьдесят тысяч строк. причем это для плана indexscan, а для secscan - всю таблицу. возможно, приемлемую быструю скорость будет показывать indexscan. иначе ускорение подобных запросов обсуждали тут и тут .

Andrey Daeronне уверен, что по типу INET для операции << PostgreSQL может использовать индекспровел тест на 8.1.9, вроде бы умеет индекс по inet использовать
Код: 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.
nalbat=> create table t1 ( f1 inet );
CREATE TABLE
nalbat=> create index i1 on t1 ( f1 );
CREATE INDEX
nalbat=>
nalbat=> explain select * from t1 where f1 << '192.168.101/24';
                                        QUERY PLAN
-------------------------------------------------------------------------------------------
 Bitmap Heap Scan on t1  (cost= 1 . 04 .. 10 . 17  rows= 615  width= 32 )
   Filter: (f1 << '192.168.101.0/24'::inet)
   ->  Bitmap Index Scan on i1  (cost= 0 . 00 .. 1 . 04  rows= 6  width= 0 )
         Index Cond: ((f1 > '192.168.101.0/24'::inet) AND (f1 <= '192.168.101.255'::inet))
( 4  rows)

nalbat=>
nalbat=> set enable_bitmapscan to off;
SET
nalbat=>
nalbat=> explain select * from t1 where f1 << '192.168.101/24';
                                     QUERY PLAN
-------------------------------------------------------------------------------------
 Index Scan using i1 on t1  (cost= 0 . 00 .. 19 . 54  rows= 615  width= 32 )
   Index Cond: ((f1 > '192.168.101.0/24'::inet) AND (f1 <= '192.168.101.255'::inet))
   Filter: (f1 << '192.168.101.0/24'::inet)
( 3  rows)
...
Рейтинг: 0 / 0
16.10.2007, 11:02
| Ответить | Цитировать | Написать  
12 сообщений из 12, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Большая база на медленной "машине"
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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