Мне интересно, может ли tailf генерировать блокирующий ввод-вывод, который замедлит реакцию сервера из-за ведения журнала.
Например, предполагая следующую настройку:
Сервер Debian 5.1 linux (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 Кбит / с)?
Хотел бы услышать, что вы думаете, ребята.
Спасибо за чтение, Максим.
Не думаю, что здесь будет какая-то блокировка ввода-вывода. Когда вы выполняете "tail -f", происходит следующее:
Как видите, медленное интернет-соединение не повлияет на шаг № 2, который в любом случае является ключом к производительности ввода-вывода.
Кроме того, tail открывает файл в режиме «только для чтения», а журналы открываются в режиме «только для добавления», так что здесь не должно быть особых блокировок, о которых стоит беспокоиться. Если вас это все еще беспокоит, то вы можете попробовать inotail который основан на последней версии linux inotify api, чтобы избежать опроса файла.
Надеюсь, это поможет, Алекс
Правильный ответ заключается в том, что процесс чтения журнала и процесс записи журнала никак не связаны. Это отдельные процессы, а не потоки. Они не разделяют память, и у них есть собственные дескрипторы файлов со своими собственными указателями дескрипторов файлов. Ни один из них никоим образом не влияет на другой. Ядро не остановит запись в файл, потому что его читает какая-то другая программа. Он будет делать что-то, чтобы ускорить его (записывать кэширование в ОЗУ, когда диск занят, разделять кеш со всеми файловыми дескрипторами, которые используют этот файл, и т.д.), но не замедлять его!
Другой ответ о том, как работает хвост, наполовину правильный. Он не использует канал для общения с bash. Bash приостанавливается в ожидании завершения (если не запускается с &). Tail наследует дескриптор файла "stdout" (по умолчанию подключенный к вашему терминалу) от bash и записывает в него напрямую. Было бы неэффективно возвращать его обратно в bash, переключать задачу на bash для чтения данных и иметь bash для записи вывода. Unix разработан, чтобы быть простым и эффективным, от стандартного ввода до стандартного вывода почти все.
Текущие версии GNU tail полностью поддерживают inotify API, чтобы избежать опроса. Обычно это не имеет большого значения для хвоста. В основном это делается для того, чтобы файловые менеджеры могли обновлять каталоги, а серверы знали, когда следует перечитывать файл конфигурации (без перезапуска сервера). У вас также может быть хвостовое отслеживание ротации журнала (обычно он сохраняет свой файловый дескриптор). Еще одно полезное дополнение - это «tac», который меняет свои входные строки. Это позволяет вам располагать самую свежую информацию вверху при обработке файла журнала для отображения в Интернете. Наконец, ccze раскрасит ваши файлы журналов для облегчения просмотра (ANSI или HTML).
Я не думаю, что это вероятно. Я считаю, что записи будут кэшироваться в оперативной памяти, и поскольку они были только что написаны, я предполагаю, что tail также будет читать эти страницы из оперативной памяти. Страницы будут периодически синхронизироваться с диском. Я был бы удивлен, если бы Apache сам заблокировался при ожидании записи журналов на диск.