форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"PostgreSQL страшно тормозит!!!"
Сообщение от Null on 19-Апр-02, 01:49  (MSK)
Имеется постгрес 7.0.2. под которым вертится база данных из 600 тысяч записей. Запросы страшно тормозят! Каждый запрос выполняется не менее 1 сек., причем даже запрос по ключевому полю (который должен мнговенно обрабатываться). Сервер вертится на локальной машине и при запросе вообще не загружается и не шуршит диском. INSERTы делала наура, SELECTы ленится. Как мне заставить этого лентяя работать? Ессно необходимые поля проиндексированы...
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "RE: PostgreSQL страшно тормозит!!!"
Сообщение от uldus on 19-Апр-02, 09:54  (MSK)
>Имеется постгрес 7.0.2. под которым вертится >база данных из 600 тысяч >записей. Запросы страшно тормозят! Размер данных в базе ? Т.е. 600 тыс. записей с цифрами или с полями text по 20 Кб в каждом. Основываясь на своем опыте могу сказать, что тормозить начинает, больше в зависимости от объема данных, если выборка идет по неиндексируемому полю. Лечение: Использование индексов и оптимизация запросов с помощью EXPLAIN. Т.е. заходишь в psql, EXPLAIN SELECT .....; Смотришь, как сработал оптимизатор, подключился ли индекс, выборка без индексов - строишь индекс или перестраиваешь запрос и т.д. Дополнительно VACUUM ANALYZE раз в день. Плюс, проведи тюнинг ОС на котором вертится PostgreSQL - увелич размер shared буфферов, еслиFreeBSD включи Spft Updates. >запрос выполняется не менее 1 >сек., причем даже запрос по >ключевому полю (который должен мнговенно >обрабатываться). Если по ключевому - чтото неладно с индексами или VACUUM ANALYZE очень давно не запускал. >диском. INSERTы делала наура, SELECTы >ленится. Как мне заставить этого >лентяя работать? Ессно необходимые поля >проиндексированы... Т.ы. уверен ? EXPLAIN использовал ? Уверен, что SELECT запрос написан оптимально ?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "RE: PostgreSQL страшно тормозит!!!"
	Сообщение от Null on 19-Апр-02, 15:09  (MSK)
	>>Имеется постгрес 7.0.2. под которым вертится >>база данных из 600 тысяч >>записей. Запросы страшно тормозят! >Размер данных в базе ? Т.е. >600 тыс. записей с цифрами >или с полями text по >20 Кб в каждом. Основываясь запись из 6 полей, средняя длина 100 байт. >Лечение: Использование индексов и оптимизация запросов >с помощью EXPLAIN. >Т.е. заходишь в psql, EXPLAIN SELECT >.....; >Смотришь, как сработал оптимизатор, подключился ли >индекс, выборка без индексов - >строишь индекс или перестраиваешь запрос >и т.д. Индексы построены, но в Explain ни слова о них не пишет, наверное не использует. >>запрос выполняется не менее 1 >>сек., причем даже запрос по >>ключевому полю (который должен мнговенно >>обрабатываться). >Если по ключевому - чтото неладно >с индексами или VACUUM ANALYZE >очень давно не запускал. А это сильно помогло для запроса по ключевому полю. >>диском. INSERTы делала наура, SELECTы >>ленится. Как мне заставить этого >>лентяя работать? Ессно необходимые поля >>проиндексированы... >Т.ы. уверен ? EXPLAIN использовал ? >Уверен, что SELECT запрос написан >оптимально ? Конкретный пример SELECT id FROM tab WHERE field1 <= X and X <= field2 ORDER BY field2-field1 LIMIT 1; Странно то, что с индексами и без индексов по полям field1 и field2 работает одинаково. MS SQL делал то же самое в 2 раза быстрее без индексов, а с индексами - в 5 раз.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "RE: PostgreSQL страшно тормозит!!!"
	Сообщение от uldus on 22-Апр-02, 09:56  (MSK)
	>запись из 6 полей, средняя длина >100 байт. Тогда 600 тысяч записей - это совсем не много. >Индексы построены, но в Explain ни >слова о них не пишет, >наверное не использует. Перестраивай запросы и индексы, чтобы индексы отобразились при EXPLAIN. Попробуй поставить поледнюю версию PostgreSQL (7.2.1), там много приятных изменений. >Конкретный пример >SELECT id FROM tab WHERE field1 ><= X and X <= >field2 ORDER BY field2-field1 LIMIT >1; field1 и field2 не timestamp ? Самый критичный блок в твоем запросе "ORDER BY field2-field1", тормозит из-за него. Попробуй начать с самого простейшего "SELECT id FROM tab WHERE field1 <= X;"и через EXPLAIN выяви на каком этапе оптимизатор забывает про индекс. Как построены индексы по field2 и field1 ? CREATE INDEX "idx_1" on "tab" USING btree ( "field1", "field2"); или по отдельности ?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "RE: PostgreSQL страшно тормозит!!!"
	Сообщение от Null on 22-Апр-02, 14:42  (MSK)
	>>Конкретный пример >>SELECT id FROM tab WHERE field1 >><= X and X <= >>field2 ORDER BY field2-field1 LIMIT >>1; > >field1 и field2 не timestamp ? Нет, bigint до этого int были. >Самый критичный блок в твоем >запросе "ORDER BY field2-field1", тормозит Нет, выборка целиком не более 10 записей. Без order by тормозит так же. Причем странно, если написать поиск по одному полю WHERE X >= field1, то запрос выполняется моментально. Если же WHERE X BETWEEN field1 AND field2, то более секунды... >Как построены индексы по field2 >и field1 ? > >CREATE INDEX "idx_1" on "tab" USING >btree ( "field1", "field2"); > >или по отдельности ? Пробовал всяко. В итоге с отдельными индексами чуть быстрее, чем вообще без индексов и время запроса меняется. Ничего, я машину на сутки поставил, она мне статистику сделала. А теперь самое интересное. Нужно ввести в базу из текстового файла около 600000 записей и потом проверить на диапазон 57000 значений X. Одну и ту же задачу я решил покрутить на разных серверах (тачка RH7.2, Athlon 1ГГц) и вот что получилось: Postgresql: insert (без индексов): 8 мин. insert (с индексами но в отдельной транзакции): 6ч 23 мин select: 23ч 48мин select count(*): 1 сек delete: 55 сек Mysql: insert (без индексов): 3.5 мин. insert (с индексами но в отдельной транзакции): 4 мин select: 20ч 32мин select count(*): 0 сек delete: 0 сек microsoft sql 7.0 (на тачке с NT Pentium III 766): insert (без индексов): 1ч 34 мин. insert (с индексами но в отдельной транзакции): 1ч 35 мин select: 11ч 12мин (как ни странно, самый быстрый по выборкам!) select count(*): 3 сек delete: 53 мин. (а здесь я не понимаю что такого сложного было) firebird (interbase 6.1) Начну с того, что заставить его работать было сложнее, чем другие. Жутко неудобный, хотя с большими возможностями. Синтаксис SQL сильно отличается, нет возможности сортировки по выражениям. insert (без индексов): 25 мин. insert (с индексами но в отдельной транзакции): 26 мин, но как-то странно подвис на завершающем commit, хотя в базу все внес. select: 32ч 12мин (самый тормозной на выборках!!!) select count(*): 8 сек delete: 31 сек
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.