Re: Большие проблемы с ядром 2.4
On Tue, 20 Mar 2001, Victor Vislobokov wrote:
> Это понятно, но глупо все-равно. Не говоря уже о том, что вроде бы
> своп в файл медленее, чем на партицию. Я всегда считал, что чем памяти
> в системе больше, тем размер свопа меньше. А так получается, что если
Это ты зря так считал. Чем памяти в системе больше, тем больше задач она
может решать одновременно. И точка. Поскольку Unix создает иллюзию
бесконечности всех ресурсов (включая память), должен быть некий запас
обеспечивающий возможность graceful degradation.
> я имею 512 метров, то я еще и своп должен гиг делать?
> У меня стоит 2.2.18 уже месяца три без перезагрузки. Полет
> нормальный.
> Даже если учитывать, что машина 32Mb ОЗУ, 64Mb SWAP, а на машине
> крутятся такие обжоры как SQUID и PostgreSQL, не говоря уже про apache,
Это PostgreSQL-то обжора? Может быть ты еще скажешь, что у него
командная строка в psql неудобная? Поставь себе Oracle 8i и ты поймешь,
что PostgreSQL это лапочка. Правда, нагрузку тянет плоховато.
Я в свое время наблюдал как выпадает в осадок Антон Чижов по поводу
нетребовательности к ресурсам Postgres.
Демонстрировал я ему некий элемент Web-интерфейса. Показываю страничку,
https, генерация табличек из базы, все как у людей,
только грузится медленно-медленно, а я извиняющимся тоном говорю:
- Вы понимаете, там машинка слабенькая - Pentium 100, 16мегабайт, диск
IDEшный.
Учитывая, что IE 5.0, которым это дело смотрели, на такой конфигурации,
работать пожалуй бы отказался.
Правда, это было давно, там стоял Debian 2.0 с Postgres 6.4.2.
Нынешний 7.1 потолще будет. Правда, и более на базу данных похож.
BLOB наконец сделали, Anonymous View в from и так далее.
А вот count без full table scan так и не умеет.
--
Victor Wagner vitus@ice.ru
Chief Technical Officer Office:7-(095)-748-53-88
Communiware.Net Home: 7-(095)-135-46-61
http://www.communiware.net http://www.ice.ru/~vitus
Reply to: