Мой взгляд на эту проблему — с точки зрения разработчика. Я пишу код, который размещается на виртуальной машине RHEL, работающей как одна из многих в корпоративной системе. Используемая файловая система — это удаленное сетевое устройство хранения данных.
У нас была высокая вариабельность простых команд во время пакетной обработки. Поэтому мы провели тест, чтобы получить больше информации, но теперь я не знаю, что мы обнаружили.
Мы запускали следующую команду каждые 30 минут и регистрировали вывод. Это копия файла размером 6 ГБ. Я вижу скачок прошедшего времени с 11 до 190 секунд, когда система занята выполнением большого количества задач, и эта тестовая команда получает мало процессорного времени.
Я вижу, что столбец "I" (входы файловой системы) заполняется, когда загрузка процессора низкая, но не когда высокая. Столбец "w" (непроизвольные свопы) также намного выше.
Мой вопрос: что происходит с этой задачей/командой, что заставляет ее работать ТАК ДОЛЬШЕ, когда время ЦП снижается? Сохраняет ли swap in/out все эти данные на каком-то другом устройстве, которое намного медленнее? Что вообще происходит во время swap in/out?
Выполняемая команда:
/usr/bin/time -a -o filename.txt cp file.txt fileCopy.txt
| Дата | Время | е | С | У | п | с | ж | я | О |
|---|---|---|---|---|---|---|---|---|---|
| 14.03.2022 | 5:19:02 | 64,9 | 16.23 | 1.03 | 26% | 3005 | 29210 | 12000016 | 12000000 |
| 14.03.2022 | 5:49:02 | 12.7 | 11.63 | 0,79 | 97% | 2069 | 76 | 0 | 12000000 |
| 14.03.2022 | 6:19:02 | 100.39 | 14.74 | 0,78 | 15% | 1034 | 29925 | 12000136 | 12000000 |
| 14.03.2022 | 6:49:24 | 191.32 | 18.86 | 0,94 | 10% | 3374 | 36164 | 12001024 | 12000000 |
| 14.03.2022 | 7:19:02 | 71.61 | 15.61 | 0,88 | 23% | 1610 | 30316 | 12000296 | 12000000 |
| 14.03.2022 | 7:49:02 | 70.73 | 17.5 | 0,91 | 26% | 1408 | 29540 | 12000072 | 12000000 |
| 14.03.2022 | 8:19:02 | 10.95 | 9.89 | 0,7 | 96% | 1709 | 75 | 0 | 12000000 |
| 14.03.2022 | 8:49:02 | 11.01 | 10.22 | 0,73 | 99% | 239 | 85 | 0 | 12000000 |
Описания столбцов из страницы руководства для /usr/bin/time
e Elapsed real time (in seconds).
S Total number of CPU-seconds that the process spent in kernel mode.
U Total number of CPU-seconds that the process spent in user mode.
P Percentage of the CPU that this job got, computed as (%U + %S) / %E.
c Number of times the process was context-switched involuntarily (because the time slice expired).
w Number of waits: times that the program was context-switched voluntarily, for instance while waiting for an I/O operation to complete.
I Number of filesystem inputs by the process.
O Number of filesystem outputs by the process.
решение1
P в этом контексте означает отношение времени ЦП, которое эта задача получила, к общему прошедшему времени. Около 100% означает почти все время, которое она была на ЦП, и поэтому ЦП был ограничен для этих запусков. В отличие от других запусков, где что-то другое было ограничивающим фактором. Больше системного (т.е. ядра) времени, чем системного времени, как это типично для задач с большим объемом ввода-вывода.
Учитывая, что рабочая нагрузка заключалась в копировании файла размером 6 ГБ, мы можем сделать вывод, что 11-секундные прогоны в среднем давали более 0,5 ГБ записей в секунду. Столбец O подтверждает одинаковое количество записей каждый раз, что соответствует простому процессу копирования одного файла.
Однако в столбце ввода наблюдаются существенные колебания. Медленные прогоны имеют примерно одинаковое количество чтений и записей. Но быстрые прогоны не выполняют никаких чтений! Я предполагаю, что файл все еще кэширован в ОЗУ с момента последнего чтения. DRAM намного быстрее, чем даже твердотельное хранилище. Что является большим приростом скорости, пока под давлением памяти ОС не сбросит кэшированные данные и не будет вынуждена снова читать из медленного хранилища.
Итак, это 200-секундная задача, которая иногда может занять 12 секунд. Вероятно, из-за кэша страниц Linux.
Поиск первопричины проблемы с производительностью часто требует более глубокого понимания всей системы, выходящего за рамки какого-либо конкретного набора показателей.
Используемая файловая система представляет собой удаленное сетевое устройство хранения данных.
Обратите внимание, что копирование происходит через сетевое хранилище, поэтому это может быть что угодно на удаленной системе или в сети между ними. Производительность удаленного хранилища. Скорости и использование сети (вероятно, IP). Или это может быть локально для этой виртуальной машины, где гость конкурирует за ресурсы со всем остальным, что работает в вашей инфраструктуре.
Всегда можно углубиться в то, как все работает. Имеет ли значение сетевое хранилище (NFS?) или вы также видите это для локального диска? 0,7 секунды времени процессора пользователя — это на самом деле довольно много работы, сколько стоит учет для управления многими системными вызовами? Что на самом деле означает занятость процессора, когда большая часть этого ждет медленной памяти и очень медленного хранилища? Непростые вопросы для ответа, однако, возможно, нет необходимости копать слишком глубоко, когда все работает адекватно.