С проблемой медленной отдачи статического контента рано или поздно сталкивается каждый сисадмин.

Проявляется это приблизительно так: иногда 3Kb картинка грузится так, как будто бы она весит 3Mb, на ровном месте начинают «залипать» (отдаваться очень медленно) css-ы и JavaScript-ы. Вы нажимаете ctrl + reload — и уже, вроде, проблемы нет, потом спустя всего несколько минут все повторяется опять.

Не всегда истинная причина «тормозов» очевидна и мы косо поглядываем то на nginx, то на хостера, то на «забитый» канал, то на «тормозной» или «глючный» браузер :)

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

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

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

Однако, недавно я заметил, что у неё есть один недостаток: «ondemand» воспринимает нагрузку на процессор, вызванную операциями ввода-вывода, как «idle». Что это значит? Это значит, что при загрузке процессора операциями ввода-вывода частота процессора зачастую остаётся на пониженном уровне, что создаёт проблемы, если ваша система страдает от печально известного линуксового бага с iowait.

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

Настройка резервного копирования уверенно занимает одно из важнейших мест в деятельности администратора. В зависимости от задач резервного копирования, типов приложений и вида данных резервное копирование может осуществляться с помощью различных инструментов, таких как rsync, duplicity, rdiff-backup, bacula и других, коих существует огромное множество.

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

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

И вот мы решили ускорять то, что и так работает быстро и, заодно, поделиться опытом того, что получилось в итоге. Конечно же я расскажу о граблях, о том где не надо HTTP/2, о том почему мы покупаем 7,6Tb NVMe SSD вместо 8x1Tb SATA SSD и много другой узкоспециализированной информации.

Давайте сразу договоримся что хранение и раздача контента это 2 разные задачи и говорить мы будем только про раздачу (продвинутый кеш)

Начнем с железа…