Убирать можно только диски-копии (raid перейдет в состояние не degraded), кстати это вариант выйти из проблемной ситуации - аккуратно извлечь из рейда половину дисков (очень опасная ситуация, можно развалить рейд если ошибетесь), на их основе создать несколько новых рейдов поменьше и переносить данные на них
p.s. настоятельно рекомендую не делать один гигантский рейд массив, лучше несколько маленьких - так конфигурация гибче.
еще рекомендую, лучший шанс, создавать не аппаратный рейд а софтовый, отвяжетесь от вендорлока производителя вашего рейд-контроллера.
хех, выглядит так будто это фейковый антивирус (такие рисуют анимацию проверки и пишут - о обнаружен вирус, купите и мы его вылечим)
Если бы не большая разница 40к и 13к то я бы сказал что это наверное тестирование памяти (антивирус смотрит процессы в памяти и проверяет все подключенные ими библиотеки)
в любой непонятной ситуации ставь скобки ;)
мне лень разбираться, нужно смотреть какой оператор какой приоритет имеет в вашем случае, скорее всего что то не так происходит, если берешь элемент массива void
только если его сделали заранее
ssh это и есть последний шанс
сервер то работает? а то слишком малые шансы что ssh подвис а все остальное работает, перезагрузка обычно самый простой способ решить проблемы (лучше конечно локализовать причину но кто этим будет заниматься у вас)
p.s. причина может быть - проблемы с сетью, там такая же ошибка выпадать должна
Такие лаги выглядят как если бы память машиины уходила в своп, когда вы ее дергаете запросом, эта память из свопа вылезает, как раз несколько секунд тратится
Еще возможно хостер оверселит дисковые подсистемы, т.е. ваш диск не ваш а используется еще клиентами хостера (это нормально, за счет оверселинга vps-ка и дешевле bare metal), т.е. ваши данные улетели из кеша, а диски нагружены другим клиентом, пока все это раскочегарится...
Найти причину можно экспериментами, рекомендую разместить на сайте простенькую страничку-тест, которая при открытии будет засекать время и выводить его в качестве ответа, затем делать что то, снова выводить и так по каждой предполагаемой причине зависания... т.е. последовательно выделить память, прочитать файл, прочитать файл по сети и т.п., делов на 5 -6 строчек, затем открывая ее в разное время со своей машины, смотреть тайминги.
уменьши тестируемое изображение в 2,3,4,.. раз и поочередно сравнивай с оригиналом
не уверен что это сработает от sharpness фильтров но попробовать можно
это мой вопрос
пока образ собирается совет, создать минимальный образ в котором ошибка воспроизводится, (ну маловероятно что там нужно nginx) и запости баг .. только хз куда, в докер?
решение не учитывает веса а еще из-за дыр в списке значений id это не будет работать как ожидается, но если завести специальное поле - счетчик и обновлять его у всех записей при удалении добавлении записей, то будет работать, только вот обновлять эффективно такой список не получится
Убирать можно только диски-копии (raid перейдет в состояние не degraded), кстати это вариант выйти из проблемной ситуации - аккуратно извлечь из рейда половину дисков (очень опасная ситуация, можно развалить рейд если ошибетесь), на их основе создать несколько новых рейдов поменьше и переносить данные на них
p.s. настоятельно рекомендую не делать один гигантский рейд массив, лучше несколько маленьких - так конфигурация гибче.
еще рекомендую, лучший шанс, создавать не аппаратный рейд а софтовый, отвяжетесь от вендорлока производителя вашего рейд-контроллера.