On Tue, May 05, 2009 at 03:32:03PM +0400, Alexey Pechnikov wrote: > > Постгресс не умеет использовать столько памяти, сколько ему сказали? > > Не верю! :) Оракл точно умеет. Причём весьма гранулярно: сегмент для > > базы, сегмент для пользовательских сессий, и т.д. А что не лезет, то > > крутится через диск. > > Умеет. Только столько памяти нет, чтобы все данные с диска в нее засунуть. > К примеру, на сервере с 1 Гб ОЗУ была у меня проблема с постгресом при обсчете > выборки в 10 Гб (данные за полгода - ровно такая отчетность требуется > заказчику) . > Обработка запроса занимала от 1-го до 2-х часов. Если в это время поступал > еще > запрос, Сервер уходил в своп навсегда. Теперь там работает эскулайт, > обсчитывая > ту же выборку в 60 раз быстрее (от 1-й до 2-х минут) - он прямо с диска > данные > берет, а не засовывает их предварительно в shared memory.
Sqlite -- с диска? Вы в этом уверены? :) А я вот сильно сомневаюсь, что sqlite открывает файл так, чтобы его содержимое не попадало в буферный кэш. Потому что умею протрассировать его и посмотреть флаги open(). :-) Так что этот пример показывает, что линуксное ядро из коробки умеет само подстроить размер буферной памяти, причём лучше, чем доморощенный DBA. > > > А вот СУБД без общей памяти, как правило, умеют работать > > > с данными на диске, а не пихают все данные в ОЗУ. > > > > Чтобы работать в 1000 раз медленнее оракла и постгресса на том же железе? > > Любите гадать на кофейной гуще? :-) Выше я привел вам пример, что происходит > с постгресом на выборках объемом много более доступной shared memory. Это пример того, как DBA не справился с настройкой базы, загнав сервер в своппинг. Нормально настроенная база не должна свопиться, независимо от того, сколько у неё сессий и сколько данных ей приходится качать через диск. > ничего не изменилось. Более того, интел обещает 1000-ядерные процессоры - > эскулайт на них будет масштабироваться _линейно_, в отличие от СУБД с > разделяемыми ресурсами. Блажен кто верует... :) -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org