высокая загрузка может вызвать сервер, зависают и ошибка, “заблокированная больше 120 секунд”?
Из lvconvert страницы справочника:
lvconvert изменит линейный логический том на зеркальный логический том или на снимок линейного объема и наоборот.
Шахта Emphasis.
Таким образом да, должно быть возможно преобразовать снимок в линейный LV или зеркало. Если это означает, что можно зеркально отразить снимок и затем использовать его в качестве линейного lv, это - что-то, что необходимо было бы испытать.
По-видимому, страница справочника и я мы wrond :P Я не забыл видеть этот материал в странице справочника, но я на самом деле не попытался преобразовать снимок в линейный LV. Видя комментарий ниже, я решил проверить его. Из того, что я вижу теперь, не возможно, что когда-либо страница справочника может подразумевать, для преобразования снимка в линейный LV. То, что является возможным использованием lvconvert, должно преобразовать зеркальный объем в линейный LV. Я думаю, что страница справочника должна быть отредактирована немного здесь.
Если кто-то действительно находит способ сделать это, сообщите мне, но от того, что я знаю теперь, я сказал бы: не возможный. Довольно логичный, когда Вы думаете о нем, потому что, преобразовывая снимок LV в линейный LV означает что-то в строке
dd if=linear of=snapshot
Otoh, можно использовать снимок в качестве логического тома отдельно. Как я объяснил здесь, LVM является просто некоторым волшебством картопостроителя устройства. Таким образом, если бы Вы взяли бы снимок LVM и затем использовали бы это для Ваших экспериментов, исходный диск не был бы затронут, но может все еще продолжать функционировать обычно одновременно.
Вы могли перейти к контролирующему интерфейсу своего облачного поставщика и проверить, не сделали ли Вы превысил максимальный IOps, указанный для Вашего устройства хранения данных, которое объяснило бы, почему это заняло много времени для сбрасывания данных кэша.
максимальный IOps доступен на Вашей странице атрибутов устройства хранения данных.
Да, может.
Это означает довольно ясно: ядро не могло запланировать задачу на 120 секунд. Это указывает на нехватку ресурсов, часто из-за доступа к диску.
irqbalance может помочь, но это не кажется очевидным. Можете ли вы предоставить нам окружение этого сообщения в dmesg , в частности трассировку стека, которая следует за ним?
Более того, это не ложное срабатывание. Это не означает, что задача висит навсегда , и утверждение является совершенно правильным. Это не означает, что это проблема для вас, и вы можете решить проигнорировать ее, если не заметите какого-либо воздействия на пользователя.
Это не может быть вызвано:
- проблемой процессора (или, скорее, это может быть безумно невероятный аппаратный сбой),
- проблема с памятью (очень маловероятно, аппаратный сбой, но не произойдет несколько раз; не недостаток ОЗУ, поскольку процесс будет
убитым), - отсутствием подкачки (
oom-killerснова).
В некоторой степени вы могли бы винить в этом нехватку памяти в том смысле, что лишение вашей системы кэширования данных в ОЗУ вызовет больше операций ввода-вывода. Но это не так просто, как «нехватка памяти».
Недавно я столкнулся с этой ошибкой в одном из наших производственных кластеров:
11 ноября 14:56:41 xxx ядро: ИНФОРМАЦИЯ: задача xfsalloc / 3: 2393 заблокирована для более 120 секунд.
11 ноября, 14:56:41 Ядро Xxxx: не испорчено 2.6.32-504.8.1.el6.x86_64 # 1
11 ноября, 14:56:41 xxx: "echo 0> / proc / sys / kernel / hung_task_timeout_secs "отключает это сообщение.
..
При дальнейшей проверке журналов sar обнаружено, что время ожидания ввода-вывода было увеличено в то же время.
И после проверки оборудования (физических дисков) обнаружены ошибки среды и другие Ошибки SCSI были зарегистрированы на одном из физических дисков, который, в свою очередь, блокировал операции ввода-вывода из-за нехватки ресурсов для распределения.
11/11/15 19:52:40: завершено pRdm 607b8000 flags = 0 TimeOutC = 0 RetryC = 0 Запрос c1173100 Ответ 60e06040 iocStatus 0048 retryC 0 devId: 3 devFlags = f1482005 iocLogInfo: 31140000
11/11/15 19:52:40: DM_ProcessDevWaitQueue: Выполняется управление задачей devId = x 11/11/15 19:52:40: DM_ProcessDevWaitQueue: Управление задачей в process devId = x
Значит, это произошло из-за аппаратной ошибки в нашем кластере.
Так что было бы хорошо, если бы вы могли проверить файл ядра, а также, если там есть утилита ipmi, проверьте список селективов ipmiutil / ipmitool команда для проверки наличия проблемы.
С уважением, VT
sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.dirty_background_ratio=5
Затем зафиксируйте изменение с помощью:
sudo sysctl -p
решено за меня ....