Как определить, что открывает временные файлы, когда я вызываю подсhell с ksh.

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

Я испытываю очень медлительность при открытии подсчетов (используя ` ` или $( ) замены команд в скриптах) в ksh на некоторых серверах Linux. Той же проблемы не существует в sh или в каком-либо другом шелле. strace указывает, что время задержки связано с вызовами stat и openat для случайно названных файлов в /tmp.

test.sh:

echo `expr 1 + 1`

команда:

strace -tttT ksh test.sh

вывод:

. . .[сокращено]. . .
1734368858.571604 stat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=708608, ...}) = 0 <0.613038>
1734368859.184765 geteuid()             = 1001 <0.000011>
1734368859.184851 getegid()             = 1002 <0.000008>
1734368859.184879 getuid()              = 1001 <0.000013>
1734368859.184913 getgid()              = 1002 <0.000007>
1734368859.184946 access("/tmp", W_OK|X_OK) = 0 <0.000020>
1734368859.185012 getpid()              = 210594 <0.000009>
1734368859.185055 openat(AT_FDCWD, "/tmp/sf0p.si0", O_RDWR|O_CREAT|O_EXCL, 0666) = 1 <1.586349>
1734368860.771539 unlink("/tmp/sf0p.si0") = 0 <0.008521>
. . .

Между stat и openat мое простое выполнение expr 1 + 1 заняло более 2 секунд времени.

Вопросы:

  1. Почему ksh создает файлы в /tmp, в то время как ни один из других шеллов (sh, bash, csh) этого не делает?
  2. Как мне начать диагностику причин, по которым эти операции могут занять 1-2 секунды?

Сервер, о котором идет речь, находится на версии: Linux 5.4.17-2136.322.6.4.el8uek.x86_64 (дистрибутив Oracle Linux Server release 8.9). Ksh версии AJM 93u+ 2012-08-01

Обновление:

Мы увидели некоторые артефакты python, создающего пустые директории в /tmp, которые несколько дней назад я обнаружил в количестве 10,000 подкаталогов в /tmp. Я удалил их все, но это не помогло производительности. Прошу прощения за недостаток знаний в Unix, но прав ли я, предполагая, что как только inode директории увеличивается для перечисления такого обширного числа подкаталогов/файлов, удаление их не уменьшает inode директории, а оставляет разреженную структуру, которую все еще нужно сканировать при всех доступах к файлам? Размер inode моего /tmp (ls -ld /tmp) в настоящее время составляет 708 КБ. Это в 172 раза больше, чем начальный размер 4096 байт. Могло ли это замедлить вызовы stat и openat, которые касаются /tmp?

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

Чтобы разобраться с проблемой, которую вы испытываете в оболочке ksh на Linux-серверах, необходимо детально проанализировать несколько ключевых аспектов.

1. Почему ksh создает файлы в /tmp, тогда как другие оболочки этого не делают?

Оболочка ksh (Korn Shell) использует временные файлы в каталоге /tmp для выполнения определенных операций, особенно связанных с подстановками команд и обработкой встроенных функций. Создание временных файлов в /tmp может быть связано с различными механизмами, такими как:

  • Поддержка расширенных возможностей: ksh поддерживает более сложные функции и возможности, чем традиционные оболочки, такие как sh или bash. Это может потребовать создания временных файлов для хранения промежуточных результатов или состояния выполнения.
  • Интерпретация подстановок: При использовании подстановок команд ($( ) или ` `) ksh может генерировать временные файлы для хранения значений или промежуточных данных, что делает этот процесс более изолированным от основной среды выполнения.
  • Конфигурации: Возможно, в конфигурационных файлах оболочки (например, .kshrc) заданы специфические параметры, влияющие на поведение оболочки при выполнении команд.

2. Как диагностировать причину задержек при выполнении операций stat и openat?

Чтобы начать диагностику, вам следует рассмотреть следующие шаги:

  • Запуск strace: Вы уже применили strace, что является отличным началом. Обратите внимание не только на время выполнения вызовов, но и на количество вызовов, их последовательность и документы, к которым они обращаются.

  • Детальный анализ каталога /tmp: Ваша гипотеза о том, что структура и размер каталога /tmp может влиять на задержки, вполне оправдана. Даже если подкаталоги были удалены, система может продолжать испытывать нагрузку при обращении к каталогу с большим количеством инодов. Для проверки структуры каталога можно использовать команды:

    ls -l /tmp | wc -l  # Количество файлов и директорий
    du -sh /tmp  # Общее использование дискового пространства в /tmp
  • Проверка системных лимитов: Ознакомьтесь с системными ограничениями и параметрами, связанными с файловой системой, памятью и процессами. Elastic Bandwidth (например, Sysctl) может также оказать влияние на производительность системы.

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

3. Влияние структуры каталога /tmp на производительность

Ваше предположение о застарелых узлах и увеличении размера инодов верно. Удаление записей из каталога не всегда освобождает занятые ресурсы или уменьшает сложность структуры. В таких случаях, рутинные операции, такие как stat и openat, могут быть задержаны из-за необходимости сканирования больших объемов метаданных.

Рекомендации

  • Очистка каталога /tmp: Периодически проводите очистку /tmp для удаления ненужных временных файлов и директорий. Это укоротит время отклика от операций, связанных с доступом к каталогу.
  • Проверка конфигурации ksh: Оцените настройки вашей конфигурации ksh, чтобы установить, возможно ли уменьшение использования временных файлов (например, использование флагов или переменных окружения).
  • Обновление и поддержка системы: Убедитесь, что все компоненты операционной системы, включая системные библиотеки и оболочку ksh, обновлены до последних стабильных версий для устранения возможных ошибок и уязвимостей.

Таким образом, этап за этапом вы сможете установить причину замедлений и оптимизировать работу вашей системы, что совершенно эффективно повлияет на открытие подшеллов в оболочке ksh.

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

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