Вы путаете ужа с ежом: memory_limit отродясь средством обеспечения безопасности и управляемости не был. Это средство типа зарока пьяницы в клубе анонимных алкоголиков: "мы выставили здеся лимит в X Mb и потому обязуемся не использовать энтими вот скриптами памяти больше чем подписались...". В итоге, всегда есть вероятность что программист опрокинет стакашкувыставит позже безумный memory_limit.
А реальные ограничения - это rlimit. Они тоже могут быть разными, даже для одного пользователя - например, для веб-скриптов и в консоли (крон).
Это те, что в примере php.ini, идущего с исходниками? Ну так это _пример_.
Типа крута?
Нет самого простого способа "сделать зашибись" (тм). Есть конкретная задача - будут и конкретные решения.
В частности, разрешить изменение memory_limit. Или вообще запускать скрипт иначе, например с другим SAPI.
Проблема дистрибутива с такими "дефолтами", нет?
Вот и увеличьте эту переменную. При необходимости - еще и лимит на число дескрипторов (как уже разбирали ранее).
С временными таблицами, возможно, уже ничего не выйдет. Попробуйте поместить раздел для временных файлов mysql (не весь /tmp !) - на tmpfs.
Ну да. Я не вижу больше 20Mb вокруг. Даже на достаточно тяжелом сайте с drupal ~ 30Mb.
Да люди самые разные глупости делают с подачи нехитрых запросов гуглу ;) Поисковик головного мозга пока заменить не умеет.
Особым скриптам - особые условия.
С этой точки зрения - вообще бекап-сервера своего не надо. Покупаете место на бекап-хостинге - и все.
Вешать какие-то публичные сервисы на бекап-сервер - конечно, глупо. Только к доступности сервера по IP или доменному имени это не имеет никакого отношения.
Параноя непричем. Доступ к сервисам, которые не являются публичными - и не должен быть таковым. Ну и отключают вход для root - вовсе не для того, чтобы себя "мучить":
Это _азы_. Самая простая причина: наиболее вероятный источник поломки - Вы. Работа под обычным пользователем не позволит Вам просто из-за опечатки снести полсервера.
И молиться?
Даже когда Вы школу закончите - "все" Вы вряд-ли сумеете перечислить.
А все потому, что ТС покуда и задачу толком не сформулировал. Он перечислил ровно _одну_ угрозу, от которой хотел бы защититься. Критично ему, например, - если зашифрованный файл просто удалят с сервера? А все Ваши "защиты" это позволяют - причем влегкую.
Бессмысленно защищаться от всего на свете ("максимальная защита" - маркетоидный бред): секс в водолазном костюме, наверно, более чем безопасный... Но кому оно надо, ы?
Вот это единственный пункт, с которым можно согласиться.
Посмотрел вокруг - больше 20Mb нигде вроде нету, с этой оценкой и считал. 128 - что-то уж больно специфическое. Я что-то проглядел и ТС давал это число?
С чего вдруг? Эта переменная контролирует те же самые механизмы RLIMIT_*, что и ulimit.
Ну, аж целых 7Gb свободно. А наши гипотетические апачи потребуют 1Gb по самой писсимистической оценке. Ы?
Пожалуйста.
Выкладывайте только зашифрованные файлы. Нет других способов защиты _в принципе_.
Это покуда блажь, а не задача.
Да там пики сглаживаются - вот и все. На месячном графике - вообще _заметен_ всплеск, где работающих воркеров было существенно больше 10.
Ну и зачем тут апача насильно ограничивать, делая из него деревянный nginx? Апач сам нафоркает себе сколько нужно потомков "если что-то немного пойдет не так" (совершенно не обязательно по вине программистов - например просто slashdot-эффект).
Посмотрите документацию, там все достаточно понятно написано: http://dev.mysql.com/doc/refman/5.1/en/midpoint-insertion.html
К сожалению, нет (в принципе) инструкций для домохозяек по изменению этого параметра. Нужно смотреть, экспериментировать - на конкретном примере нагрузки.
Вот в примере и советовали, еще как. Объясните почему: лично я не вижу от этого большего выигрыша, в сравнении с консервативным значением ~40-50. Да, апачи не заграбастают порой памяти чуть больше чем Вам хочется - зато обработка запросов не будет насильно стопориться в одном месте.
Ага. Бред сивой кобылы (тм).
Запросто может выйти - что архитектура проекта из нескольких _дешевых_ серверов куда выгоднее большого и дорогого обогревателя...
