Медленный доступ к файлам Linux в /tmp

Вопрос или проблема

time touch /tmp/test.dat

real    0m1.03s
user    0m0.00s
sys     0m1.02s

Целая секунда системного времени для создания файла в /tmp. Это может стать непереносимым для скриптов ksh, которые открывают десятки файлов в /tmp для обработки в дочерних оболочках.

strace показывает время на вызове openat:

strace -tttT touch /tmp/test.dat

. . . [clip] . . .
1737560680.004656 close(3)              = 0 <0.000013>
1737560680.004750 openat(AT_FDCWD, "/tmp/test.dat", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3 <1.370377>
1737560681.375253 dup2(3, 0)            = 0 <0.000026>
. . . [clip] . . .

Текущий ЦП в ходе этих тестов имеет 70-80% простоя. Достаточно памяти. /tmp использовано только на 1%, хотя под ним находится много пустых каталогов (5,268). Сервер работает уже 96 дней. У нас была эта проблема на другом сервере, который по какой-то причине паниковал и перезагружался. После перезагрузки проблема исчезла – доступ к /tmp снова был быстрым. Таким образом, что-то со временем приводит к тому, что доступ к /tmp становится все медленнее и медленнее, и перезагрузка это исправляет.

Версия ОС: 5.4.17-2136.322.6.4.el8uek.x86_64, разработанная Oracle (это вычислительный узел Exadata)

Монтирование /tmp: /dev/mapper/VGExaDb-LVDbTmp xfs 45G 45M 45G 1% /tmp

Поддержка Oracle развела руками (если честно, они особо и не пытались). Есть ли у кого-то из гуру Unix идеи, что можно сделать? Какие вещи могут быть причиной такой медлительности?

Есть ли у кого-то из гуру Unix идеи, что можно сделать?

Если вы арендуете хранилище, и доступ к нему занимает 1 сек, а у вас нет привилегий для отслеживания данных между вашими программами и хранилищем:

Ни один гуру ничего не смогут сделать; им нужно быть поддержкой вашего облачного провайдера. Очень ясно, что ваше /dev/mapper/VGExaDb-LVDbTmp испытывает чрезмерно высокую задержку, и это не то, что вы можете исправить из пользовательского пространства.

Какие вещи могут быть причиной такой медлительности?

Поврежденное оборудование. Сильно загруженная пропускная способность хранилища. Проблемы с разрешением пользователей (например, LDAP медленно работает из-за каких-то проблем с DNS, а сервер не настроен на кэширование учетных данных). Полная перегрузка ЦП. Миллион процессов, удаляющих и создающих файлы на той же файловой системе, пока вы это делаете.

Таким образом, что-то со временем приводит к тому, что доступ к /tmp становится все медленнее и медленнее, и перезагрузка это исправляет.

Возможно, реально есть какой-то другой длительный процесс, который действительно нагружает эту файловую систему изменениями метаданных? Звучит маловероятно. Более вероятно, что хранилище очень медленное и после более долгого времени работы все кэши заполнены. К сожалению, это опять-таки вопрос, который нужен вашему облачному провайдеру, если только вы не видите огромного потребления ЦП на вашем узле, что, скорее всего, вы бы заметили раньше.

.

Ответ или решение

Теория

Проблема, связанная с медленным доступом к каталогу /tmp, как описано в вашем вопросе, может быть вызвана множеством факторов, которые влияют на файловую систему и её взаимодействие с оборудованием или ОС. /tmp — это каталог, который обычно используется для временного хранения файлов и часто монтируется как файловая система в оперативной памяти (tmpfs), но в данном случае он смонтирован как XFS, что указывает на то, что временные файлы фактически хранятся на диске. Учитывая, что другие серверы не страдают от данной проблемы после перезагрузки, это указывает на потенциальные проблемы с кэшированием, накоплением состояния системы или аппаратным обеспечением.

Основные теоретические причины медленного доступа могут включать:

  1. Перегрузка дисковой подсистемы: Когда дисковая подсистема перегружена, это существенно замедляет операции записи и чтения. Это может быть вызвано избытком процессов, конкурирующих за доступ к тому же устройству.

  2. Проблемы с кэшированием: Долгое время работы без перезапуска может приводить к накоплению мусора в системных кэшах, что делает доступ к файловой системе менее эффективным.

  3. Проблемы аппаратного обеспечения: Иногда сбои в аппаратной части, такие как неисправные диски, могут вызывать значительные задержки.

  4. Проблемы с виртуализацией и сетевыми файловыми системами: Если /tmp работает на виртуализованной инфраструктуре или использует сетевое хранилище, то задержки могут быть вызваны проблемами на более низком уровне.

  5. Переполненная файловая система или метаданные: Несмотря на то, что использование /tmp всего 1%, может быть проблема перегрузки в метаданных из-за большого количества малых файлов или директорий.

Пример

Как видно из вашего вывода strace, проблема возникает на этапе openat, который тратит более секунды, что и вызывает задержку. Это указывает на увеличенное время обращения к устройству хранения при попытке открыть файл для записи. Перезагрузка, которая временно решает проблему, может свидетельствовать о том, что кэширование или высокая нагрузка на диск снижаются после перезапуска.

Применение

Существует несколько шагов, которые вы можете предпринять для диагностики и, возможно, решения проблемы:

  1. Мониторинг дисковой активности: Используйте инструменты, такие как iotop, чтобы отследить процессы, активно использующие диск, и определить, какие процессы создают значительную нагрузку на /tmp.

  2. Профилирование файловой системы: Утилита xfs_info может помочь определить статус метаданных на файловой системе XFS и выявить аномалии.

  3. Проверка кэша и буферов: Убедитесь, что системные кэши и буферы не переполнены. Одним из потенциальных решений может быть очистка кэша с использованием команды sync; echo 3 > /proc/sys/vm/drop_caches.

  4. Анализ загрузки CPU и памяти: Даже если общая загрузка процессора невысока, проверьте, нет ли всплесков загрузки в системных потоках или обособленных ядрах, которые могут мешать обработке файловых операций.

  5. Обновление системы и патчи: Убедитесь, что ваша ОС и файловые системы обновлены до последних версий, так как патчи могут содержать исправления для известных проблем с производительностью.

  6. Перезагрузка как временное решение: Хотя это не идеальный выход, временная автоматическая перезагрузка сервера может рассматриваться, чтобы избегать накопления системных ошибок, до тех пор пока не будет найдено устойчивое решение проблемы.

Проблемы такого рода могут потребовать времени и тесного взаимодействия с администратором системы или Oracle Support, особенно если потенциальная проблема связана с глубокими аспектами конфигурации хранилища или неполадками в инфраструктуре. Однако, тщательный системный анализ часто помогает выявить корень проблемы.

Оцените материал
Добавить комментарий

Капча загружается...