Может ли хвост замедлить скорость записи журналов в Linux (ext3)?
Мне интересно, может ли tailf генерировать блокирующий ввод / вывод, который замедлит скорость отклика сервера из-за регистрации.
Например при условии следующей настройки:
Linux-сервер Debian 5.1 (foo), управляемый через терминал (foo размещен на EC2).
Foo запускает несколько приложений, каждое из которых записывает в свой собственный файл журнала. В качестве примера, Apache httpd в /var/log/apache/access.log и Tomcat 5.5 в /var/log/tomcat5.5/myApp.log.
Если я открываю ssh-соединение с foo (примечание: интернет-ссылка, высокая задержка, относительно медленная загрузка) и запускаю tail -F /var/log/apache/access.log я не могу достичь ситуации, когда ядро блокирует записи httpd в этот файл журнала и, таким образом, замедляет производительность httpd из-за ожидания, навязанного каждому потоку?
Чтобы привести некоторые цифры, давайте предположим, что foo регистрирует ~200 КБ данных журнала в секунду, которые необходимо передать по проводному соединению клиенту ssh.
Еще один теоретический аспект: что произойдет, если файловая система / var / log установлена на оперативную память бесконечного размера (помните: теоретически), чтобы исключить время поиска жесткого диска?
Третий аспект: что произойдет, если я открою соединение ssh с очень медленной ссылки (предположим, что foo имеет трафик, формирующий загрузку только 5 Кбит / с)?
Хотелось бы услышать, что вы думаете, ребята.
Спасибо за чтение, Максим.
3 ответа
Я не думаю, что здесь будет какая-то блокировка ввода / вывода. Когда вы делаете "tail -f", происходит
- ваш процесс оболочки, скажем, bash, создаст новый процесс 'tail'.
- tail откроет файл, переместит указатель файла в конец, подождет 3 секунды и проверит наличие новых данных.
- если появятся новые данные, tail вернет их обратно в bash, используя канал unix.
- эти данные передаются с сервера на ваш компьютер с помощью bash + ssh.
Итак, как вы можете видеть, медленное интернет-соединение не повлияет на шаг № 2, который в любом случае является ключевым для производительности ввода-вывода.
Кроме того, tail открывает файл в режиме "только для чтения" и, догадываясь об этом, журналы открываются в режиме "только для добавления", поэтому здесь не нужно сильно беспокоиться. Если это все еще немного беспокоит вас, вы можете попробовать inotail, основанный на последней версии linux inotify api, чтобы избежать опроса файла.
Надеюсь, это поможет, Алекс
Я не думаю, что это вероятно. Я верю, что записи будут кэшироваться в оперативной памяти, и, поскольку они только что были написаны, я думаю, что tail будет также читать эти страницы из оперативной памяти. Страницы будут периодически синхронизироваться с диском. Я был бы удивлен, если бы Apache блокировал ожидание записи журналов на диск сам.
Правильный ответ заключается в том, что процесс, читающий журнал, и процесс, пишущий журнал, никак не связаны. Это отдельные процессы, а не потоки. Они не разделяют память и имеют свои собственные файловые дескрипторы со своими собственными указателями файловых дескрипторов. Ни один из них никак не влияет на другого. Ядро не остановит запись в файл, потому что какая-то другая программа читает его. Он будет ускорять его (записывать кеширование в ОЗУ, когда диск занят, делиться кешем со всеми файловыми дескрипторами, использующими этот файл и т. Д.), Но не замедлять его!
Другой ответ о том, как работает хвост, наполовину прав. Он не использует трубу, чтобы поговорить с Башом. Bash приостанавливается в ожидании завершения (если не выполняется с &). Tail наследует файловый дескриптор "stdout" (по умолчанию подключенный к вашему терминалу) от bash и записывает в него напрямую. Было бы неэффективно передавать его обратно в bash, переключать задачи в bash для чтения данных, а команда bash записывает вывод. Unix разработан, чтобы быть простым и эффективным, от stdin до stdout для большинства всего.
Текущие версии GNU tail полностью поддерживают API inotify, чтобы избежать опроса. Это обычно не имеет большого значения для хвоста. В основном это так, что файловые менеджеры могут обновлять каталоги, а серверы знают, когда перечитывать файл конфигурации (без перезапуска сервера). У вас также может быть хвостовой ротации журналов (обычно он сохраняет свой файловый дескриптор). Другое полезное в стороне - "tac", который обратит свои входные строки. Это позволяет вам иметь самую последнюю информацию вверху при обработке файла журнала для веб-отображения. Наконец, ccze раскрасит ваши файлы журналов для более удобного просмотра (ANSI или HTML).