survivor Опубликовано 13 мая, 2014 · Жалоба Доброго дня! Никак не могу разобраться в чем дело - время от времени виснет виртуальная машина, причем так что даже консоль не посмотреть. Performance закладка (на ESXi) показывает взлетевшие вверх графики CPU (как будто сервер начал считать что-то очень ресурсоемкое), нормальные показатели по памяти, полный ноль сетевой активности (сервер даже не пингуется). После ребута VM в ее логах ничего подозрительного. Сервер работал лет 6 без каких-либо проблем. Хоть в какую сторону искать проблему? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 13 мая, 2014 · Жалоба Доброго дня! Никак не могу разобраться в чем дело - время от времени виснет виртуальная машина, причем так что даже консоль не посмотреть. Performance закладка (на ESXi) показывает взлетевшие вверх графики CPU (как будто сервер начал считать что-то очень ресурсоемкое), нормальные показатели по памяти, полный ноль сетевой активности (сервер даже не пингуется). После ребута VM в ее логах ничего подозрительного. Сервер работал лет 6 без каких-либо проблем. Хоть в какую сторону искать проблему? Память умерла? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 13 мая, 2014 · Жалоба Доброго дня! Никак не могу разобраться в чем дело - время от времени виснет виртуальная машина, причем так что даже консоль не посмотреть. Performance закладка (на ESXi) показывает взлетевшие вверх графики CPU (как будто сервер начал считать что-то очень ресурсоемкое), нормальные показатели по памяти, полный ноль сетевой активности (сервер даже не пингуется). После ребута VM в ее логах ничего подозрительного. Сервер работал лет 6 без каких-либо проблем. Хоть в какую сторону искать проблему? Подозрения два: 1) блок питания 2) память Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MiB Опубликовано 13 мая, 2014 · Жалоба на госте freebsd? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 14 мая, 2014 · Жалоба tartila на этом же физическом сервере под ESXi еще штук 6 виртуальных машин, нигде такой проблемы нет. Скорее всего проблем с физической памятью нет. Alex/AT аналогично :) MiB ESXi 5.0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 14 мая, 2014 · Жалоба удивляет сам факт происходящего - при полном исключении проблем с физикой (память, БП и т.д.) и внешнем воздействии (не атака - траффика абсолютный ноль) и маловероятной внутренней угрозе (из пользователей только я), без каких-либо изменений в ПО, без внезапно увеличившейся нагрузки - NIXсистема может просто взять и зависнуть - не дав логов, не показав на экране какую-то ошибку. Такое ощущение что где-то в ядре происходит деление на ноль ))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Merridius Опубликовано 14 мая, 2014 (изменено) · Жалоба А нет такого, что машина постоянно в ready очереди стоит? Она отвисает со временем или только после ресета? Изменено 14 мая, 2014 пользователем Merridius Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 14 мая, 2014 · Жалоба отвисает только после ресета. Насчет ready очереди не понял Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Merridius Опубликовано 14 мая, 2014 · Жалоба Если виртуалок больше чем ядер и они постоянно хотят выполнять какой-то код, они помещаются в ready очередь. Т.е. встают в очередь на получение ядра для обработки кода. Поскольку ядро выделяется машине на определенный промежуток времени, то как только он заканчивается, машина "замораживается" и переходит в очердь wait, если она опять хочет выполнять код, то опять в ready, а дальше в run. Это если настройки резерваций и шары выставлены по дефолту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Merridius Опубликовано 14 мая, 2014 · Жалоба Вообще не факт, что нет проблем с оперативкой. Может просто остальные 6 машин не обращаются к участку памяти на дохлой планке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 14 мая, 2014 · Жалоба Если виртуалок больше чем ядер и они постоянно хотят выполнять какой-то код, они помещаются в ready очередь. Т.е. встают в очередь на получение ядра для обработки кода. Поскольку ядро выделяется машине на определенный промежуток времени, то как только он заканчивается, машина "замораживается" и переходит в очердь wait, если она опять хочет выполнять код, то опять в ready, а дальше в run. Это если настройки резерваций и шары выставлены по дефолту. ага понятно. Нет, приоритезацию и шаринг ресурсов я настраивал, у этой машины наивысший приоритет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BiWiS Опубликовано 15 мая, 2014 · Жалоба Есть такая же точно проблема, один в один выглядит как у вас. Из дюжины ВМ повисает все время одна и та же, в произвольные промежутки времени. В госте стоит Linux xxx.host.ru 2.6.18-274.17.1.el5 #1 SMP Tue Jan 10 17:25:58 EST 2012 x86_64 x86_64 x86_64 GNU/Linux ESXi 5.0.0, 469512 До сих пор так и не выявилась причина. Кстати, если машину так надолго оставить висеть, то через сутки-двое повиснет и ESXi. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 15 мая, 2014 · Жалоба на этом же физическом сервере под ESXi еще штук 6 виртуальных машин, нигде такой проблемы нет. Скорее всего проблем с физической памятью нет. Было ровно то же самое (только одна машина из 11, плюс если оставить висеть - вис весь ESXi потом через какое-то время), сменил БП - грабля исчезла. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
FATHER_FBI Опубликовано 19 мая, 2014 (изменено) · Жалоба Для начала: 1. Посмотрите в логах гипервизора что происходило в виртуалкой перед смертью 2. Проверьте память на наличие ошибок, что бы все планки памяти были одного вендора и с одинаковыми таймингами 3. Образ esxi самосборный (esxi customizer) или официальный? 4. Как виртуалка оказалась на гипервизоре? Делалась чистая установка через vsphere или протолкнули готовую VM/OFV через vmware workstation? P.S. Было бы не плохо узнать версию вашего гипервизора и железо на котором оно стоит. Изменено 19 мая, 2014 пользователем FATHER_FBI Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bespud Опубликовано 28 июня, 2015 · Жалоба Всем здрасте. Вобщем была такая же ситуация - виртуалка win2008svrR2std на ESXi 5.5 (standalone) висла 4-6 раз в месяц. В основном по ночам. Без каких либо записей в логах. Я уже готов был менять RAID с ADaptec 4605 на что-то иное, потому что очень часто эта проблема встречалась у людей с этим контроллером, что даже подтверждали обе техподдержки. (vmware и adaptec). Вобщем я вылечил всё разбитием файла подкачки на 2 диска. У меня 32гб памяти, файл подкачки в данный момент у меня на системном диске и на быстром рэйде по 32гб. И проблема исчезла. Вернул весь файл подкачки на системный диск в размере 64гб = проблема стала проявляться с той же периодичностью. Опять разбил - снова сплю спокойно. Надеюсь кому-то эта инфа сэкономит кучу нервов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 28 июня, 2015 · Жалоба сменил БП - грабля исчезла. мне интересно как вы до этого дошли? методом тыка, меняли все элементы по одному или же как-то осознанно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 28 июня, 2015 · Жалоба Виндоус сервера обычно лечатся методом научного тыка :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 28 июня, 2015 · Жалоба да не суть, виндоус или не виндоус, мне интересно как человек понял(или не понял, а угадал?) что дело в БП Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shader Опубликовано 29 июня, 2015 (изменено) · Жалоба да не суть, виндоус или не виндоус, мне интересно как человек понял(или не понял, а угадал?) что дело в БП чаще всего, если происходит что-то "невероятное"(Виснут программы или же полностью ОС, без каких либо сообщений перед смертью) - то это очень похоже на некачественное питание. Проверить несложно. Прийти в серверу и раскрутить БП. В 95% случаев будет видно подутые ёмкости на выходе. У меня есть старенький сервер, на котором я раз в 3 года перепаиваю ёмкости на БП. PS. Если же автор имеет ввиду удалённое выявление неисправности БП, то тут, думаю, 100% методов нет. Без эндоскопии никак :) Изменено 29 июня, 2015 пользователем shader Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...