Re: xserver-xorg и hal
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
Reply to: