Мы пытаемся диагностировать медленно работающую виртуальную машину изнутри виртуальной машины.
Ситуация:
База данных сообщает о значительном времени ожидания асинхронного сетевого ввода-вывода, т.е. ожидая, пока приложение потребляет данные. Виртуальная машина приложения также явно немного загружена: ~ 20% ЦП. Инфраструктура не принадлежит нам, и наш единственный доступ - через RDP к виртуальной машине и SQL Management Studio к кластеру базы данных. У нас нет достаточных прав для запуска профилировщика, хотя мы записываем счетчики производительности как для базы данных, так и для виртуальной машины.
Несколько недель назад скорость обработки сообщений резко упала на 70-80%. Насколько нам известно, ничего не изменилось: приложение не было изменено или перенастроено, а счетчики производительности не показывают изменений характеристик нагрузки. Владельцы инфраструктуры заявили, что с их стороны ничего не изменилось.
В рамках процесса перезапуска приложение было вынуждено перезагрузить свою очередь сообщений. Это включает в себя один простой SELECT из нескольких сотен тысяч строк, которые затем считываются в структуры в памяти. База данных обслужила SELECT за несколько секунд, но затем ждала ~ 10 минут, пока приложение считывает набор результатов. Это однопоточная операция, включающая очень простую десериализацию, и не должна занимать более пары минут на этом оборудовании.
Моя текущая теория заключается в том, что сетевая задержка каким-то образом увеличилась, но ping сообщает только «<1 мс», и у нас в любом случае нет базового показателя. hrPing сообщает время от 0,5 до 2 мс от сервера приложений до базы данных.
Другая возможность заключается в том, что реальная емкость ЦП виртуальной машины каким-то образом уменьшилась, но я ожидал, что это проявится как увеличенная «кажущаяся» нагрузка.
Доступны ли нам другие способы расследования?
Я ни в чем не разбираюсь, но вот мои 2 цента:
1) Устраните сомнения:
Сделайте 2 передачи больших папок из БД на сервер приложений и обратно примерно по 500 МБ. 1 Папка должна содержать один двоичный файл размером 500 МБ. Вторая папка должна содержать тысячи / миллионы файлов размером 1 КБ или меньше и видеть производительность сети для каждого случая. Первый покажет вам имитацию потока с большим количеством пакетов и высокой полезной нагрузкой, второй (который будет имитировать транзакции БД) покажет вам моделирование потока с большим количеством пакетов и низкой полезной нагрузкой. Это даст вам представление о том, какая сетевая среда у них есть и верны ли ваши сетевые проблемы. Имейте в виду, что коммутационная способность - это не только скорость порта. Прибытие 10 МБ / с в 10 пакетах НЕ является такой же нагрузкой на коммутатор (загрузка ЦП коммутатора), как поступление 10 МБ / с в 100000 пакетов ... Коммутатор должен передавать каждый отдельный пакет независимо от полезной нагрузки, и вы можете получить насыщение сети легко, если у вас недостаточно коммутационной способности (пакетов в секунду). Вероятно, это (99,9%) не будет иметь место в центре обработки данных, но вы никогда не узнаете наверняка, пока не протестируете
2) Конфигурация приложения 2-й точки:
Я надеюсь, что это ваше приложение, и вы его правильно настроили, в противном случае большинство драйверов JDBC имеют пакетные транзакции, которые иногда, если явно не определены в вашем провайдере сохранения, могут вызывать поведение, подобное тому, что вы испытываете (приложение ожидает определенной суммы операций записи перед фактической фиксацией транзакции или ожиданием ряда операций чтения перед выполнением запроса). Даже в этом случае у этих пакетных операций есть таймауты, которые составляют порядка секунды или 2, тогда они фиксируют транзакции, независимо от того, заполнена ли очередь пакетной обработки или нет.
3) Мелкий шрифт контракта на третье облако точек:
Теперь, поскольку это облачный провайдер, обратите внимание на мелкий шрифт. Тип транзакции, о которой вы говорите, будет включать в себя большое количество транзакций на хост-шине. Большинство провайдеров теперь ограничивают использование шины для каждой виртуальной машины, но они не афишируют это (вы найдете ограничение на gt / s). Поэтому, когда данные прибывают, передача их из сетевого интерфейса через шину в RAM ваших виртуальных машин оказывает огромное влияние (имейте в виду, что ваши виртуальные машины не совпадают по ресурсам, поэтому они не получают одинаковые общие ресурсы и, таким образом, простой рабочая нагрузка сети варьируется). Хороший индикатор того, что вы ограничены, - это соединение 1G, попытка передать большой двоичный непрерывный файл локально без нагрузки и никогда не достигать 50 ~ 60 МБ / с (450-480 Мбит / с).
В любом случае надеюсь, что это поможет
Спасибо за все предложения! Ситуация в конечном итоге разрешилась, хотя нам не сказали, что это было - хост виртуальной машины или сеть, и что именно было сделано, чтобы исправить это.
В процессе устранения неполадок мы написали простое приложение для профилирования определенных операций с базой данных и попытаемся точно определить, каким образом платформа не работает:
https://github.com/BluewireTechnologies/db-latency
По сути, база данных statistics time заявлено, что прошло 0 мс, в то время как иногда клиент SQL был почти уверен, что потратил несколько сотен миллисекунд на ожидание возврата ExecuteReader (), указывая на сетевую проблему или, возможно, на виртуальную машину, испытывающую нехватку временных интервалов. Эти всплески влияют на около 5% обращений к базе данных и дают обычно мгновенным операциям высокую вероятность выполнения нескольких секунд.
Один из технических специалистов заказчика сам скомпилировал и использовал инструмент. Он подтвердил наши выводы и отправил их соответствующей группе, и через несколько часов проблема была решена.
Действительно кажется вероятным, что, как все подозревали, это была проблема с сетью!