Онлайн-сервис взорван! Это оказался горшок из бревна! !

Java Linux

GitHub 18k Star Путь Java-инженера к тому, чтобы стать богом, не приходите и не узнайте об этом!

Путь Java-инженера GitHub 18k Star к тому, чтобы стать богом, разве вы не хотите узнать об этом!

GitHub 18k Star Путь инженера Java к тому, чтобы стать богом, на самом деле не приходите, чтобы узнать об этом!

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

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

проблемный процесс

Во время определенной акции в онлайн-приложении внезапно возникло большое количество тревог, свидетельствующих о слишком высоком уровне использования диска, который когда-то достигал более 80%.

В этом случае мы впервые заходим на онлайн-машину и проверяем использование диска онлайн-машины. Используйте команду: df для просмотра использования диска.

$df
Filesystem     1K-blocks    Used Available Use% Mounted on
/               62914560 58911440 4003120  93% /
/dev/sda2       62914560 58911440 4003120   93% /home/admin

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

Вставьте сюда фон,Наши онлайн-машины настроены на автоматическое сжатие и очистку журнала.Когда отдельный файл достигает определенного размера или содержимое машины достигает определенного порога, он будет запускаться автоматически.

Но в тот день не было большой акции по очистке журнала, из-за чего машина отключилась после истощения.

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

du -sm * | sort -nr
512 service.log.20201105193331
256 service.log
428 service.log.20201106151311
286 service.log.20201107195011
356 service.log.20201108155838

du -sm * | sort -nr : подсчитать размер файлов в текущем каталоге и отсортировать их по размеру

Поэтому, пообщавшись со студентами-эксплуатационниками, мы решили провести экстренное лечение.

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

rm service.log.20201105193331

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

$df
Filesystem     1K-blocks    Used Available Use% Mounted on
/               62914560 58911440 4003120  93% /
/dev/sda2       62914560 58911440 4003120  93% /home/admin

Итак, мы начали выяснять, почему после удаления журнала не освобождалось место на диске.С помощью команды мы обнаружили, что есть процесс, все еще читающий файл.

lsof |grep deleted
SLS   11526  root   3r   REG   253,0 2665433605  104181296 /home/admin/****/service.log.20201205193331 (deleted)

Роль lsof |grepDeleted состоит в том, чтобы просмотреть все открытые файлы и отфильтровать файлы в удаленном состоянии.

После расследования этот процесс является процессом SLS, который постоянно считывает содержимое журнала с машины.

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

У нас LiveJournal будет собираться по SLS, поэтому путем анализа мы выяснили, что не освобождается место на диске, и журнал SLS читаем.

На данный момент проблема в основном обнаружена, поэтому давайте вставим принцип и представим базовые знания, стоящие за ним.

жизненный опыт

В системе Linux удаление файлов контролируется количеством ссылок, и только если у файла нет ссылок, файл будет удален.

Вообще говоря, у каждого файла есть 2 счетчика ссылок: i_count и i_nlink, то есть:Только когда i_nlink и i_count равны 0 в системе Linux, этот файл будет удален.

  • i_count указывает количество текущих пользователей файла (или вызванных)
  • i_nlink представляет количество медиа-соединений (количество жестких ссылок);
  • Можно понять, что i_count — это счетчик обращений к памяти, а i_nlink — счетчик обращений к диску.​

Когда на файл ссылается процесс, соответствующий i_count будет увеличиваться; когда создается жесткая ссылка на файл, соответствующий i_nlink будет увеличиваться.

В системах Linux или Unix удаление файла с помощью rm или файлового менеджера просто удаляет его из структуры каталогов файловой системы, что фактически уменьшает счетчик ссылок на диск i_nlink, но не уменьшает количество i_count.

Если файл вызывается процессом и пользователь «удаляет» файл с помощью команды rm, файл не может быть найден с помощью команд управления файлами, таких как ls, но это не означает, что файл действительно удален с диска. .

Поскольку есть еще один процесс в нормальном исполнении, прочитал или пишет в файле, то есть файл на самом деле «удален», поэтому дисковое пространство всегда будет занято.

И наша онлайн-проблема заключается в этом принципе, потому что есть процесс, работающий с файлом журнала, поэтому операция rm на самом деле не удаляет файл, поэтому место на диске не освобождается.

проблема решена

После понимания явления онлайн-проблемы и вышеприведенных базовых знаний мы можем придумать способ решения этой проблемы.

То есть найти способ убить ссылку процесса SLS на этот файл журнала, файл можно действительно удалить, а место на диске можно действительно освободить.

kill -9 11526
$df
Filesystem     1K-blocks    Used Available Use% Mounted on
/               62914560 50331648 12582912  80% /
/dev/sda2       62914560 50331648 12582912  80% /home/admin

В качестве специального напоминания, прежде чем выполнять kill -9, обязательно обдумайте, каковы последствия выполнения., принцип может относиться к:Мой сервер для выполнения kill -9 после того, как он уведомлен, на следующий день не приходят!

После этого после повторного рассмотрения мы обнаружили, что существует две основные причины для такой проблемы:

  • 1. Слишком много онлайн-журналов распечатываются слишком часто
  • 2. Скорость вытягивания бревна SLS слишком низкая.

После тщательного анализа мы обнаружили, что это приложение печатает много журналов процессов. Первоначальная печать журнала предназначена для удобства устранения неполадок в Интернете или для анализа данных, ноВ период акции объем журналов резко увеличился, что привело к быстрому увеличению использования дискового пространства.

Кроме того, поскольку приложение и несколько других крупных приложений совместно используют проект SLS,В результате скорость вытягивания SLS снижается, что, в свою очередь, приводит к тому, что процесс никогда не заканчивается.

После этого мы также подвели некоторые улучшения.Что касается второго вопроса, мы разделили конфигурацию SLS приложения и управляли ею независимо.

На первый вопрос, т.В период действия акции была введена стратегия понижения версии журнала: при заполнении диска версия журнала понижается.

Что касается ухудшения журнала, я разработал общий инструмент, который динамически проталкивает уровень журнала через конфигурацию и динамически изменяет уровень вывода онлайн-журнала. И настройте модификацию этой конфигурации на нашу платформу плана и выполняйте регулярную или экстренную обработку плана в период действия акции, чтобы избежать этой проблемы.

Идеи разработки и связанные с ними коды инструмента понижения версии журнала будут представлены вам в следующей статье.

считать

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

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

Поэтому я всегда думал,Судить о том, гений ли программист, можно по его способности решать задачи!

Об авторе:Hollis, человек с уникальным увлечением программированием, технический эксперт Alibaba, соавтор «Трех курсов для программистов» и автор серии статей «Дорога к Java-инженерам».

Если у вас есть комментарии, предложения или вы хотите пообщаться с автором, вы можете подписаться на официальный аккаунт [Hollis], оставьте мне сообщение прямо на заднем плане.