/usr/local/bin/safe_file_backup. у меня так называется.
безболезненность лишь относительно других обычных программ. некоторое повышение нагрузки все равно заметно и скорость тоже приходится ограничивать.
совершенно точно, что кеш этим решением не вымывается .
Вижу, идею вы поняли. Но зачем вы описываете как не надо делать?
rsync, как и многие другие программы, кеш попортит.
как и изготовление дампов в виде sql.
Все это конечно становится важно, если ничего другое не помогает.
Вот именно : нагрузок нет, но предельное значение вы выставляете избыточно большое. Иногда, по разным причинам число апачей может резко увеличиться. Предельное значение MaxClients это защита от инвалидации кеша файлов ОС. Вот 50-60 и поставьте.
Можно выбрать такой скрипт бекапа, который кеш не затрагивает вообще.
Хотя, если сделать простой и достаточно медленный бекап, то данные будут успевать "влетать назад" в кеш и все тоже пройдет плавно.
можете попробовать при загрузке mysql исполнять операторы LOAD INDEX INTO CACHE, но на хостинге неизвестных сайтов это целая проблема, выбрать горячие индексы. Опять палка о двух концах: они загрузят в память вообще все части индексов, в том числе и не нужные. Обычно никто не рестартит mysql. Я бы в вашем случае потерпел.
Да, это глупо. Mysql точно лучше ОС знает какие файлы ему кешировать внутри себя. Индексы почти всегда приоритетнее данных.
я за то, чтобы попробовать кеш небольшого размера - 512мб. Но это только предположение.
это collation - правила сравнения.
_ci - case insensitive , регистронезависимое.
_cs - case sensitive, регистрозависимое
_bin - binary, двоичное, то есть сравниваются отдельные символы как последовательности байт.
_general для utf8 показывает, что правильно сравниваются только основные символы, а во всяких там редких алфавитах может не работать правильно. русский - не редкий.
выбирай согласно задаче.
stepan007, вместе с nginx вам решительно не нужно MaxClients 250. Это все тоже повлияет на использование памяти.
Вообще, я заметил, что вы неправильно понимаете механизм кеширования.
В широком смысле кеширование это и key_buffer у mysql и кеш eaccelerator. вы пытаетесь сделать кеш такого размера чтобы поместились все данные, но это не нужно и невыгодно, так как приводит к перерасходу памяти и свопингу как у вас.
У вас действительно порядка нескольких Гб php-кода ? Зачем использовать php-cli ? это хостинг или что?
С тех пор как Одноклассники научили людей писать в интернете, они слишком легко пишут ерунду.
По крайней мере кеш eacelerator бессмысленно держать в tmpfs, если его можно поместить в память внутренними средствами. Логи, как правило, пишутся многими программами буферизировано и большой нагрузки не добавляют. Вы больше потеряете от отключения slow-log в mysql.
такой длительный бекап неизбежно выносит все кеши. я уже обращал внимание на это в начале темы.
stepan007, содержимое tmpfs точно так же может быть вытеснено в своп при этом не будет ассоциировано ни с одним процессом.
С чего вы вообще решили использовать tmpfs ?
Если поставить eaccelerator.shm_only = "1", то он должен использовать память вместо диска без дополнительных ухищрений в виде tmpfs.
Ну и как и раньше, нет смысла гнаться за гигантскими размерами кешей. Пусть кеширует только самые важные скрипты.
и mysql-slow.log совершенно не понятно с какой целью хранить в памяти.
myhand, еще можно сказать "не извлекаете дополнительную прибыль от эксплуатации на еще немного большей нагрузке". так ведь уже совсем другая окраска без изменения технически предпринятых действий и не выглядит глупо. пользуйтесь этой формулировкой .
не эксплуатируете системы на пределе возможностей.
по остальным пунктам полностью не согласен.
Реально это произошло только через год, когда вышел etch. Это ж дебиан. Так у них всегда.
Не закономерно, а странно. Бедблоки всю дорогу были и на маленьких и на больших дисках.
Наоборот, чем меньше диски тем более ненапряжно их проверять. А вот на терабайтниках проверка затянется и выльется в неприятные проблемы в понедельник утром.
ну как бы md raid был задолго до 2007. саму возможность запускать проверку приделали в 2.6.16 - март 2006. А сам raid включили в ядро где-то в 1996 году в 1.3.69.
т.е. 10 лет вопрос о необходимости сверки массива не был насущным и разработчиков не волновал.
учитывая это, разве не очевидно, что большинству на эту проверку наплевать?
