Я бы создал создал второй "сломанный" raid1 из одного нового диска. Потом и скопировал бы на него файлы, установил загрузчик и загрузился уже со второго. А после замены sda можно синхронизировать raid1 как обычно и ставить туда загрузчик.
Если сбойные сектора вообще ничего полезного не содержали, то может все удачно и быстро пройти.
Загрузка с другого диска потребует некоторой внимательности и понимания процесса загрузки, но это вполне реально.
ну тут же все понятно :) Программер прийде - порядок наведе !
традиционные методы для программиста - использование полноценных профайлеров типа php-xdebug.
С практической точки зрения администраторы решают эту же задачу делая поверхностные предположения об исчерпании тех или иных ресурсов, но профилирование - самый логичный. Он покажет какой именно кусок кода php самый медленный. Тормозит функция создания сессий - это сразу всплывет.
не понятно почему именно кеши усиливают вероятность, а хардверные рейды нет. Вы же не читаете данные в обход кешей ? Если flashcache сделан как устройство dm, как вообще можно прочитать мимо ? там же почти всегда что-то несовместное.
Или дело только в том, что с кешами плотность размещения VPS еще больше и операций записи больше?
Pavel.Odintsov, не понятна суть явления. каким именно образом данные приходят в негодность ?
даже при таких потребностях создавать php.ini не нужно, можно обойтись php -d session.save_path = .
Но пользователи могут и захотеть иметь свой php.ini
ну тогда напрягитесь и сделайте вместо /usr/bin/php свой скрипт-враппер, который определяет кто его вызвал, подставляет нужный php.ini, запускает уже сам php.
EvGenius, речь идет о предоставлении услуг хостинга или вы для своих личных сайтов хотите этого?
Можно же просто запускать не просто /usr/bin/php, а соответствующими ключами и конфигурационным файлом.
Lubimov, чет не работает ваша классика.
С:\>
"pingdom.com" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
Вообще-то ulimit должен ограничивать размер одного процесса. когда процесс вырастает больше чем задано он убивается системой. При этом родительский процесс практически никогда большим не бывает. Да и процесс-обработчик тоже до 2 гб не дотягивает обычно. Так что это вполне безопасно.
Но сдается мне, вы что-то не так объясняете. Где именно вы взяли цифру 2048 мб ? Это в сумме или один процесс ?
Если хостер это насчитал у себя, в таком случае с ним и разбирайтесь.
как раз поэтому батарейка и полезна. нагрузка от такого поведения mysql довольно высокая и батарейка позволяет ее избежать.
Но мы все-таки в разделе "Хостинг для нищего веба", поэтому следует понимать, что под mysql Pavel.Odintsov понимает myisam. Либо innodb, где обязательную запись транзакций отключают и всем рекомендуют потому что так модно.
