Короче говоря, у меня есть два идентичных сервера, на которых размещаются виртуальные машины с использованием VirtualBox, и на обоих серверах размещается одна виртуальная машина, каждая из которых настроена почти одинаково, только одна - производственная, а другая - для внутренних тестов и разработки. Важно то, что оборудование и ОС сервера идентичны, что обе виртуальные машины используют одну и ту же ОС и запускают в основном одно и то же программное обеспечение, только сценарий использования немного отличается. Проблема в том, что я сталкиваюсь с серьезными проблемами производительности на производственной виртуальной машине для некоторых рабочих нагрузок после некоторого времени выполнения, которые я не могу воспроизвести для внутренней виртуальной машины.
Все программное обеспечение в виртуальной машине в целом работает «нормально», без ошибок, просто некоторые рабочие нагрузки могут создавать такую высокую нагрузку / накладные расходы / что угодно на виртуальной машине, что она становится чрезвычайно медленной и непригодной для использования. После нескольких часов работы даже перезапуск ClamAV-daemon уже вызывает проблему. Я могу запустить его с некоторой особой нагрузкой на Tomcat, и во всех случаях есть массивный процессор и хотя бы некоторые общие операции ввода-вывода. Но только в prod тестовая виртуальная машина с таким же количеством процессоров, оперативной памяти и т. Д. Работает должным образом. Даже в prod-VM проблема не возникает сразу после перезапуска, кажется, только после нескольких часов работы.
Сейчас я сравниваю sysctl -a обеих систем и проверьте, какие различия могут привести к проблемам с производительностью. Одно различие заключается в следующем:
fs.aio-max-nr = 65536
fs.aio-nr = 0
vs.
fs.aio-max-nr = 65536
fs.aio-nr = 2661
Первая - это производственная ВМ. У меня есть другие ВМ с 0 тоже, но некоторые тоже с отличным от 0. Поскольку prod- и test-VM размещают очень похожее программное обеспечение, httpd, Tomcat7, Postgres 9.6, настраиваемые службы Perl и т. Д., Для меня не имеет никакого смысла иметь 0, а другой нет. Из того, что я прочитал, 0 просто означает, что никто не использует асинхронный ввод-вывод в prod-VM, а только в test-VM. Что очень маловероятно из-за того же программного обеспечения.
Поэтому я предполагаю, что по какой-то причине существует некоторая разница в конфигурации, которая заставляет программное обеспечение в prod-VM думать, что оно не может использовать асинхронный ввод-вывод, что может значительно снизить производительность в моем случае использования.
Пока aio-max-nr очевидно, не проблема, существуют ли другие настройки, пакеты, библиотеки или что-то еще, что может повлиять на то, что программное обеспечение считает, что асинхронный ввод-вывод недоступен?
Единственное, что я обнаружил, касалось программного обеспечения, но не относилось к тому программному обеспечению, которое я использую или упоминал. fs.aio-max-nr как возможное узкое место, что, очевидно, не относится ко мне.
В прошлом казалось, что следующее, по крайней мере, проверить, доступен ли асинхронный ввод-вывод, в принципе, работало, что, похоже, больше не так, ни в одной из моих систем ничего не найдено.
grep kio /proc/slabinfo
https://kbflow.wordpress.com/2013/02/25/check-if-async-io-is-enabled-in-centos/ https://www.systutorials.com/linux-kernels/125888/patch-aio-remove-kioctx-from-mm_struct-linux-2-6-15/
Следующее действительно предоставляет некоторые данные и результаты одинаковы в обеих системах:
ls -l /sys/kernel/slab | grep kio
lrwxrwxrwx 1 root root 0 Apr 18 13:03 aio_kiocb -> :t-0000128
lrwxrwxrwx 1 root root 0 Apr 18 13:02 kioctx -> :t-0000640
https://community.oracle.com/message/14732908#14732908
Не уверен, что мне говорят эти данные, некоторые данные одинаковы на обеих виртуальных машинах, некоторые отличаются, особенно objects_partial является 0 снова на прод-ВМ. Я надеялся найти какой-нибудь простой переключатель или что-то подобное в каком-нибудь файле конфигурации. :-)
AIO включен в самом ядре:
cat /boot/config-4.4.0-119-generic | grep AIO
CONFIG_AIO=y
CONFIG_COMEDI_AIO_AIO12_8=m
CONFIG_COMEDI_AIO_IIRO_16=m
CONFIG_DELL_WMI_AIO=m
Я обнаружил разницу в своей настройке: MySQL. Остановка того, что устанавливает fs.aio-nr к 0, начиная с 2661 очередной раз. Это задокументировано для необязательного использовать AIO и можно найти советы по настройке также.
Итак, AIO, скорее всего, не является причиной моих проблем с масштабированием, потому что он включен в ядре и fs.aio-max-nr достаточно высока. И я предполагаю, что это общий ответ на мой вопрос: обе настройки должны быть в порядке, а все остальное просто зависит от конкретного приложения. Либо он использует AIO, либо нет, скорее всего, нет других дополнительных глобальных / общесистемных настроек, влияющих на это решение.