> max_connection = 256;
а вы уверены что это хотябы рядом стояло с оптимизацией???
возьмите табличку на 100 000 000 записей или более, чтоб она весила больше Shared Memory раза в 2-3. и сделайте параллельно 256 выборок по индексу с фильтром и лимитом в сотню строк… т.е. обеспечте выборку со всех частей таблицы(в реальной жизни это почти всегда так)
В чём прикол тратить дисковое пространство на HD, когда качество картинки просто отвратительное… Через такую дырку(оптику) качественное фото(видео) не получить, накрутка цены за счёт надписи HD, ну и увеличение количество продаж носителей, типа двойная выгода…
что у chromium, что у firefox куча процессов. даже после того как пару firebug'ов съедает всю память в том числе и весь своп, я закрываю только firebug и память сразу освобождается.
возможно из кучи ОС не может освобождать пока с верхушки не освободится, тогда эта проблема уже не firefox, а либы в ОС которая работает с памятью. соответственно таже проблема должна всплывать у вас и с chrom'ом. в разных дистрибутивах по всей видимости это работает по разному. по крайней мере в ALTLinux всё хорошо.
чесно говоря странно называть нормальную работу firebug утечкой памяти. ведь firebug от начала своей работы ведёт статистику ошибок, ajax запросов и т.д. и всё это накапливается где? только в памяти(возможно в localStorage, но он ограничен в районе 5Мб).
в Chrom'е так называемая «консоль разработчика» так же со временем накапливает много всего и не чуть не хуже firebug'а сжирает пару гигов оперативы.
Почему они не освобождают память путём удаления старых данных, потому что средства разработки не могут знать нужны эти данные разработчику ещё или нет. И только разработчик должен следить за памятью…
Не знаю как в винде, но в версии под linux в firefox можно одним кликом по значку жука включать и выключать firebug, причём для каждой вкладки отдельно(каждая вкладка отдельный процесс), тем самым освободить память. Тоже самое для Chrome, закрываем консоль и нет проблемы.
И не надо никого убивать и принуждать это делать других…
а вы уверены что это хотябы рядом стояло с оптимизацией???
возьмите табличку на 100 000 000 записей или более, чтоб она весила больше Shared Memory раза в 2-3. и сделайте параллельно 256 выборок по индексу с фильтром и лимитом в сотню строк… т.е. обеспечте выборку со всех частей таблицы(в реальной жизни это почти всегда так)
как вы думаете, как скоро вы получите результат?
# pstree.....................
├─kdeinit4─┬─bash───java───21*[{java}]
│ ├─chromium-browse─┬─chromium-browse
│ │ ├─chromium-browse───5*[chromium-browse───{chromium-browse}]
│ │ ├─chromium-browse───3*[{chromium-browse}]
│ │ └─15*[{chromium-browse}]
│ ├─firefox───xulrunner─┬─plugin-containe───3*[{plugin-containe}]
│ │ └─12*[{xulrunner}
.....................
что у chromium, что у firefox куча процессов. даже после того как пару firebug'ов съедает всю память в том числе и весь своп, я закрываю только firebug и память сразу освобождается.
возможно из кучи ОС не может освобождать пока с верхушки не освободится, тогда эта проблема уже не firefox, а либы в ОС которая работает с памятью. соответственно таже проблема должна всплывать у вас и с chrom'ом. в разных дистрибутивах по всей видимости это работает по разному. по крайней мере в ALTLinux всё хорошо.
в Chrom'е так называемая «консоль разработчика» так же со временем накапливает много всего и не чуть не хуже firebug'а сжирает пару гигов оперативы.
Почему они не освобождают память путём удаления старых данных, потому что средства разработки не могут знать нужны эти данные разработчику ещё или нет. И только разработчик должен следить за памятью…
Не знаю как в винде, но в версии под linux в firefox можно одним кликом по значку жука включать и выключать firebug, причём для каждой вкладки отдельно(каждая вкладка отдельный процесс), тем самым освободить память. Тоже самое для Chrome, закрываем консоль и нет проблемы.
И не надо никого убивать и принуждать это делать других…