форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"OpenNews: Исследование производительности PostgreSQL 8.3"

Сообщение от opennews (??) on 20-Фев-08, 21:44

Иван Золотухин исследовал (http://postgresmen.ru/articles/view/83) эффект от обновления PostgreSQL с версии 8.2 до 8.3. Приведены графики, на которых видно заметное улучшение производительности системы за счёт снижения интенсивности работы с дисками. В итоге, после миграции на PostgreSQL 8.3, было зафиксировано снижение общей загруженности сервера в 2-3 раза. Причины улучшения производительности -  Читающие транзакции не приводят к проматыванию идентификатора транзакции (xid), соответственно отсутствует запись в pg_clog, которая раньше имела место быть даже при немодифицирующих запросах.-  Распределенные checkpoint-ы. PostgreSQL научился "размазывать" процесс синхронизации буферов с файлами данных на диске, более равномерно распределяя нагрузку на систему.-  Улучшенные seqscan-ы. Речь идет не только о Syncronized Scans, но еще и о том, что раньше seqscan по большой таблице, которая не лежит в shared_buffers, приводил к вытеснению "грязных" буферов из памяти и PostgreSQL вынужден был прямо сразу записывать их на диск (даже при простом немодифицирующем запросе). Начиная с версии 8.3 существует специальный буфер фиксированного размера для последовательных просмотров и PostgreSQL читает данные с диска в него, не вытесняя при этом существенные порции "грязных" данных на диск, как это было раньше. URL: http://postgresmen.ru/articles/view/83 Новость: http://www.opennet.me/opennews/art.shtml?num=14333

Высказать мнение | Ответить | Правка | Cообщить модератору

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

[Сортировка по времени | RSS]

1. "Исследование производительности PostgreSQL 8.3"

Сообщение от Аноним (??) on 20-Фев-08, 21:44

Надо бы посмотреть как в динамике будет развиваться в этой ситуации. А то свежераздампленная база постгреса всегда раз в полтора быстрее старой на той же версии сервер, из-за отсутствия лишних версий, меньшего места на диске и более точных планов.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Исследование производительности PostgreSQL 8.3"
	Сообщение от pavel_simple (??) on 20-Фев-08, 21:50
	В 8.3 действительно много изменений касательно производительности -- все ведут к повышению быстродействия по объективным причинам Молодцы !
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Исследование производительности PostgreSQL 8.3"

Сообщение от ufaweb (ok) on 20-Фев-08, 21:56

догоним и перегоним MySQL?)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Исследование производительности PostgreSQL 8.3"
	Сообщение от Konwin (ok) on 21-Фев-08, 00:00
	>догоним и перегоним MySQL?) Ну вы сравнили - промышленную СУБД с СУБД уровня приложений :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Исследование производительности PostgreSQL 8.3"
	Сообщение от smb on 21-Фев-08, 00:03
	+1 было бы что догонять. смотришь на тесты falcon - и понимаешь кривоту рук мускульовцев, лучший движок ведь innodb(имхо!!), не обновлявшийся кучу лет и скупленный ораклом....
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Исследование производительности PostgreSQL 8.3"
	Сообщение от Кирилл (??) on 21-Фев-08, 09:41
	>+1 > >было бы что догонять. смотришь на тесты falcon - и понимаешь кривоту >рук мускульовцев, лучший движок ведь innodb(имхо!!), не обновлявшийся кучу лет и >скупленный ораклом.... инодб лучший движок? ))))) Это обычный ISAM двадцатилетней давности.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Исследование производительности PostgreSQL 8.3"
	Сообщение от Аноним (??) on 21-Фев-08, 17:37
	Но тем не менее - это лучшее что есть у MySQL :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Исследование производительности PostgreSQL 8.3"
	Сообщение от Aleksey (??) on 21-Фев-08, 07:58
	Как я понимаю читать надо: "Ну вы сравнили - промышленную СУБД (PostgreSQL) с СУБД уровня приложений (MySQL) :)"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Исследование производительности PostgreSQL 8.3"
	Сообщение от Konwin (ok) on 21-Фев-08, 10:05
	>Как я понимаю читать надо: "Ну вы сравнили - промышленную СУБД (PostgreSQL) >с СУБД уровня приложений (MySQL) :)" Совершенно верно
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Исследование производительности PostgreSQL 8.3"

Сообщение от Аноним (??) on 20-Фев-08, 23:59

бжжж... а разве не давно перегнали? скорее ораклу нужно будет подвинуться :D

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Исследование производительности PostgreSQL 8.3"
	Сообщение от parad (ok) on 21-Фев-08, 09:31
	>бжжж... а разве не давно перегнали? скорее ораклу нужно будет подвинуться :D да, через пару лет по производительности постгрес будет стоять на ровне с монструальным (не путать с менструальным) ораклом. однако по кол-ву разных вкусностей оракл будет лидировать до тех пор, пока в постгре не начнут собирать, сортировать и накапливать модули под разные нужды, например, как это сделано в перле - cpan; все для этого уже имеется - потрясающий апи, удобная портируемость, гибкие настройки. а так - хорошая работа - великолепный пример успешного BSD проекта. также радует, что все чаще в заголовках интересных новостей все чаще встречаются имена русских девелоперов. молодцы, так держать!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Исследование производительности PostgreSQL 8.3"

Сообщение от Veter (??) on 21-Фев-08, 18:18

На выборках из нескольких таблиц версия 8.3 в несколько раз медленнее версии 8.1 с той же базой, да еще на более сложных запросах временами строит кривой план выполнения (в 8.1 на тех же запросах строит нормальный). До промышленного использования версии 8.3 еще немало времени пройдет. Релиз очень интересный, но его надо "доводить до ума". Хотя на серверах с перегруженной дисковой подсистемой стоит уже и задуматься, т.к. нагрузка на диск существенно уменьшилась, что может для кого-то стать спасением.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Исследование производительности PostgreSQL 8.3"

Сообщение от Veter (??) on 21-Фев-08, 18:24

Кстати, сравнивать версии 8.3 и 8.2 некорректно - версия 8.2 медленнее, чем 8.1. К тому же в постгресе четные версии скорее полигон, чем продакшен. Намного интереснее сравнить с 8.1. Кроме того, работа с базой в ОЗУ слишком вырожденный случай. Про планировщик запросов ни слова, видимо, чтобы не вспоминать о грустном.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Исследование производительности PostgreSQL 8.3"
	Сообщение от Иван Золотухин on 21-Фев-08, 19:46
	работа с базой в ОЗУ -- 95% случаев, так как 4-8ГБ памяти позволить себе все могут, а объем баз у большинства людей вообще меньше гигабайта, о чем тут говорить. пока люди не перестанут думать о том, что это вырожденный случай, новички будут кричать, что mysql быстрее postgresql, при этом даже не удосуживаясь поменять конфиг и положить всю БД в память. тут даже спорить нечего.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Исследование производительности PostgreSQL 8.3"
	Сообщение от Veter (??) on 21-Фев-08, 21:45
	Постгрес хорош не в качестве записной кннижки, а как СУБД уровня предприятия. И mysql здесь абсолютно не конкурент (низкая надежность, нет набора встраиваемых языков для организации бизнес-логики в СУБД, примитивный планировщик, "прожорливость" по отношению к ОЗУ и процессорному времени, etc.) Сравнивать стоит с ораклом, но утверждение, что на оракле 95% баз помещается в ОЗУ, совершенно несостоятельно. Что касается ниши пхп+мускул, так тут вообще в 95% случаев (не считал, может, и в 99%, просто позаимствовал число у вас) можно без реляционных СУБД обойтись. С ораклом тягаться тяжело, однако крупные проекты можно с успехом реализовывать на постгресе, во многом благодаря его расширяемости и встроенной поддержке скриптовых языков. И при больших базах, которые не помещаются в ОЗУ, постгрес умеет работать, но есть свои проблемы, которые требуют больше или меньше времени на их решение или поиск обходных путей, пока в этом классе задач версия 8.1 выигрывает особенно, когда запросы под эту версию уже оптимизированы) и смысла переходить на 8.3 нет. P.S. Неужели ваша компания предлагает услуги коммерческой поддержки форумов на домашних страничках и не интересуется корпоративным сектором? Может, я что-то не понимаю, но как раз мускульщики коммерческого интереса не представляют (за редким исключением). А найти информацию об использовании постгреса в крупном бизнесе почти нереально, увы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Исследование производительности PostgreSQL 8.3"
	Сообщение от Иван Золотухин on 26-Фев-08, 12:37
	>P.S. Неужели ваша компания предлагает услуги коммерческой поддержки форумов на домашних страничках >и не интересуется корпоративным сектором? Может, я что-то не понимаю, но >как раз мускульщики коммерческого интереса не представляют (за редким исключением). А >найти информацию об использовании постгреса в крупном бизнесе почти нереально, увы. Ну чушь какую-то вы говорите. Во-первых, 2-3 ГБ *активных* данных -- это не домашняя страничка. Во-вторых, да, таких инсталляций подавляющее большинство, не вижу в этом ничего плохого. У нас даже большинство клиентов (а это компании среднего размера) с 1С имеет такие базы. В-третьих, из этого не следует, что оставшимся 5% клиентов не нужна помощь. Крупный бизнес тоже использует PostgreSQL, но тщательно это скрывает и зачастую пока не решается использовать его в mission critical задачах, в отличие от компаний среднего размера, которые все же более поворотливы и имеют меньше стереотипов. Смею вас заверить, что мало кто лучше астрономов разбирается в оптимизации баз, которые совсем не ложатся в память (т.е. гигантских баз), а у нас имеется именно астрономический опыт, который мы успешно применяем в коммерческих проектах. Что касается 8.3 и баз, не влезающих в RAM, читайте рассылки -- уже полно usecase-ов, однозначно свидетельствующих в пользу новой версии. Я пытаюсь сказать лишь одно на самом деле: Постгрес хорош на любых объемах данных; в самом популярном сегменте небольших баз он абсолютно ни в чем (в т.ч. по скорости) не уступает остальным СУБД. Пока мы совместными усилиями не популяризируем эту простую идею, крупный бизнес не будет знать о PostgreSQL, потому что о нем не говорят на каждом перекрестке.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Исследование производительности PostgreSQL 8.3"
	Сообщение от Антон (??) on 21-Фев-08, 22:19
	>работа с базой в ОЗУ -- 95% случаев, так как 4-8ГБ памяти >позволить себе все могут, а объем баз у большинства людей вообще Покажите, pls, пример настроек конфига postgres, связанных с памятью, при 4-8Гб оперативы ? shared_buffers сколько лучше поставить, а то сильно задирать боязно, уж больно мало по дефолту стоит. Остальное что-нибудь нужно тюнить, или shared_buffers увеличить достаточно ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Исследование производительности PostgreSQL 8.3"
	Сообщение от Иван Золотухин on 26-Фев-08, 12:42
	>>работа с базой в ОЗУ -- 95% случаев, так как 4-8ГБ памяти >>позволить себе все могут, а объем баз у большинства людей вообще > >Покажите, pls, пример настроек конфига postgres, связанных с памятью, при 4-8Гб оперативы >? shared_buffers сколько лучше поставить, а то сильно задирать боязно, уж >больно мало по дефолту стоит. Остальное что-нибудь нужно тюнить, или shared_buffers >увеличить достаточно ? Антон, по такому короткому описанию оптимальную конфигурацию указать сложно. Все зависит от ваших данных, характера работы приложения с ними. Грубо, вам можно пытаться увеличивать shared_buffers до 1-2 ГБ, аккуратно измеряя эффект после изменения. Остальные параметры тоже можно тюнить, но вслепую я не решусь о них говорить.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]