У меня похожая проблема была, правда, с самого начала с момента получения указанного сервера. Решилось заменой сервера. Здесь описал чуть подробнее.
tolik777: А то последний раз такое наблюдалось 27 декабря. Потом столько дней все нормально, а вот за эти сутки 3 downtim'а.
Не связываете это с нагрузкой? Мой вышеуказанный сервер без нагрузки (из-за глюков приходилось перенаправить трафик на другой сервер) работал отлично многие дни, но как только пытался нагрузить его - сразу появлялись проблемы. К Новому году и несколько дней после него нагрузка запросто могла упасть (в зависимости от категории проектов).
Буквально недавно свеже-заказанный в Hetzner сервер без каких-либо записей в логи вис намертво (что помогала только перезагрузка вручную через службу поддержки), либо внезапно перезагружался.
После некоторого общения со службой поддержки они заменили сервер с переносом дисков с первого на новый, и проблема на этом решилась. За что им и благодарен.
poiuty: Если есть подозрения, что проблема с железом - в дц могут его проверить. Занимает это 10-14 часов. Это стандартно, независимо берете ли вы через реселлера или напрямую.
Перед заменой сервера делали такую проверку - она ничего не показала.
bsyomov: Выделять всё место под один раздел не очень удачная идея.
Речь идёт о всём свободном месте.
myhand: Чем лучше?
Данные, которые нужно поместить в этот раздел, занимают более 2TB места. Конечно, их можно попытаться раскидать по разным разделам - но всё это выглядит не очень аккуратно. Да и оставшееся свободное место в этих разделах используется не оптимально в этом случае.
myhand: Обе - не самые удачные.
Может быть вам известно под мои требования (свободное пространство 3TB диска - в одном разделе) более удачное решение, чем приведённые примеры разметок в первом сообщении?
Предположим, это решит проблему тормозов при создании временных файлов на диске MySQL-сервером. А как заставить систему использовать всю оперативку под кеш?
/var/lib/nginx/ на нее поставьте 777
Не помню теперь, пробовал ли этот вариант уже, когда искал ошибку. Обновлю опять и проверю.
А вы сталкивались с подобным? Есть догадки почему в разных версиях это работает по-разному?
может обновится до стабле ?
Я обновил до той, что в репозитории epel для CentOS была (актуальная). Думаете, что дело всё же в баге nginx?
client_max_body_size по умолчанию?
Сейчас установлено client_max_body_size 64m. Много? Можно уменьшить, но почему под предыдущими версиями проблем не вызывало, а только под актуальной?
tolik777,
У меня похожая проблема была, правда, с самого начала с момента получения указанного сервера. Решилось заменой сервера. Здесь описал чуть подробнее.
А то последний раз такое наблюдалось 27 декабря. Потом столько дней все нормально, а вот за эти сутки 3 downtim'а.
Не связываете это с нагрузкой? Мой вышеуказанный сервер без нагрузки (из-за глюков приходилось перенаправить трафик на другой сервер) работал отлично многие дни, но как только пытался нагрузить его - сразу появлялись проблемы. К Новому году и несколько дней после него нагрузка запросто могла упасть (в зависимости от категории проектов).
Буквально недавно свеже-заказанный в Hetzner сервер без каких-либо записей в логи вис намертво (что помогала только перезагрузка вручную через службу поддержки), либо внезапно перезагружался.
После некоторого общения со службой поддержки они заменили сервер с переносом дисков с первого на новый, и проблема на этом решилась. За что им и благодарен.
Если есть подозрения, что проблема с железом - в дц могут его проверить. Занимает это 10-14 часов. Это стандартно, независимо берете ли вы через реселлера или напрямую.
Перед заменой сервера делали такую проверку - она ничего не показала.
после чистки зубов обычной щеткой
Тогда уж купите электрическую щётку. Весьма стоящая вещь.
Благодарю всех за ответы.
Выделять всё место под один раздел не очень удачная идея.
Речь идёт о всём свободном месте.
Чем лучше?
Данные, которые нужно поместить в этот раздел, занимают более 2TB места. Конечно, их можно попытаться раскидать по разным разделам - но всё это выглядит не очень аккуратно. Да и оставшееся свободное место в этих разделах используется не оптимально в этом случае.
Обе - не самые удачные.
Может быть вам известно под мои требования (свободное пространство 3TB диска - в одном разделе) более удачное решение, чем приведённые примеры разметок в первом сообщении?
Под который/чей кеш?
Под системный кеш. Тогда, возможно, и БД оказалась бы в этом кеше (?).
Сделайте то, что вас просили
Попробую.
Сделайте для tmp ramdisk
Предположим, это решит проблему тормозов при создании временных файлов на диске MySQL-сервером. А как заставить систему использовать всю оперативку под кеш?
P.S. Все БД вместе размером, примерно 10 Гб.
должно быть намного больше
WTF?! Не хватает желтизны? 😕
Виталий Макаркин,
Из заголовка и текста темы непонятно, в чём заключается ваш вопрос. Что вам нужно-то?