Я устал испытывать определённые опасения за сохранность данных на выделенном сервере, наблюдая за происходящим у хостеров последнее время… 3FN, Agava, Hosting.UA, МакХост — тенденция получается очень нехорошая.

В итоге, МакХост стал последней каплей, и, чтобы не оказаться в числе тех, кто «уже делает бекапы», я перевёл систему бекапов своего сервера на Amazon S3. Получилось вполне себе быстро и прозрачно.

Хочу поделиться с общественностью простейшей реализацией.

Дело было вечером, делать было нечего… Дернуло меня поглядеть на QtScript, на котором пишутся плагины для Амарока, ну, думаю, просто смотреть неинтересно — надо чего-то написать. Ну, а так как я в это время слушал музыку именно из Контакта, так как не для кого не секрет, что там можно найти практически все, то было решено заменить совсем неудобный плеер контакта на Амарок, дабы была возможность нормально этим делом управлять посредством мультимедийныйх клавиш и да и просто для объединения в один плейлист композиций локальных и сетевых.

Вступление

Недавно мне потребовалось перенести несколько сайтов различных клиентов на нормальный выделенный сервер (не виртуальный). Я давно выбирал, где лучше арендовать сервер и выбором стала немецкая компания Hetzner Online и ее тарифный план DS 3000 (AMD Athlon 64 X2 4200+/2Gb DDR/2x160Gb HDD — как выяснилось потом — на сервере оказалось два винчестера по 320Гб).

Но мне не хотелось всех размещать на одном сервере. Поэтому было решено сделать виртуальные машины на базе технологии XEN (к тому же в придачу к серверу на ТП DS 3000 Hetzner Online бесплатно выдает 6 IP-адресов, которые очень удобно будут смотреться для отдельных проектов). В Сети можно найти много информации по теме настройки и самого XEN'а на Debian'e и настройки роутинга на нем, поднятии виртуалок на LVM (lvm дает большее быстродействие, чем виртуалки на базе image-файлов), даже в вики самой фирмы была информация об этом (но на немецком — Google Translate нам в помощь). Но. Было одно «Но». Она вся была разрозненная и кусками. Я нигде не смог найти толкового пошагового руководства для настройки «от» и «до».

Поэтому, всем кому интересна эта тема,

В данном разделе опишу как использовать возможности OpenSSH для создания Layer 3 туннелей, применительно к OS Debian GNU/Linux (наверняка без особых проблем заработает и в Ubuntu).

Сегодня я расскажу на абстрактном примере как правильно создать *.deb пакет для Ubuntu/Debian. Пакет мы будем делать бинарный. Пакеты, компилирующие бинарники из исходников здесь не рассматриваются: осилив изложенные ниже знания, в дальнейшем по готовым примерам можно понять суть и действовать по аналогии :)

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

В качестве бонуса в конце статьи будет пример быстрого создания собственного локального репозитория: установка пакетов из репозитория позволяет автоматически отслеживать зависимости, и конечно же! — устанавливать всё одной консольной командой на нескольких машинах :)

Для тех, кто не хочет вдаваться в мощную систему установки софта в Linux, рекомендую посетить сайт проги CheckInstall: она автоматически создаёт deb-пакет из команды «make install» ;) А мы вместе с любопытными —

Начиная с версии 0.8.11 в nginx появилась новая возможность для раздачи статики — использование AIO (Asyncronous Input-Output — неблокирующий ввод-вывод) для Linux и FreeBSD.

Чем это событие знаменательно? До этого момента nginx использовал неблокирующий режим только при работе с сетью — любая работа с файлами блокировала рабочий процесс. К чему это приводило? Если у вас есть много разного контента, который не весь находится в кэше ОС (фотохостинг, etc) — то рано или поздно все 50, 150, 200 процессов будут ждать дисковые операции и не смогут обслужить нового клиента — даже если нужный ему контент можно отдать из файлового кэша или запросить с бэкенда.

Статья написана по материалам моего доклада на CodeCamp 2009.

Для многих из нас настает тот долгожданный день, когда аудитория сайта начинает стремительно расти. Каждое утро мы, затая дыхание, смотрим на графики google analitycs и расплываемся в улыбке, когда взят рубеж в очередную тысячу посетителей в день. Как правило, рост посещаемости не совпадает с ростом технической базы и сайт начинает тормозить. Тут в игру вступает сисадмин...

У любого проекта всегда есть что оптимизировать: можно почитать советы по оптимизации на webo.in, установить eaccelerator, memcache, проиндексировать поисковые поля в базе данных. Я предполагаю, что все это уже проделано, а сайт по прежнему тормозит.

Пришло время оптимизировать nginx...

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.

Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*

Если выбирать, кэшировать ли страницу на стороне PHP или на стороне nginx, я выбираю nginx. Во-первых, это позволяет отдавать 5-10 тыс. запросов в секунду без каких-либо сложностей и без умных разговоров о «высокой нагрузке». Во-вторых, nginx самостоятельно следит за размером кэша и чистит его как при устаревании, так и при вытеснении нечасто используемых данных.

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

Доброе утро, Хабр!

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

Как вы все помните, в конце предыдущего поста я обещал более подробно рассмотреть вкратце и максимально доступно следующие вопросы:

1. Настройка DHCP
2. Поднимаем свой DNS по минимуму
3. Съем статистики по интерфейсам при помощи snmp и отрисовывание красот в cacti
4. Лимитирование по трафику пользователей внутри сети
5. Ведение детальной статистики по тому, как куда и кем расходуется трафик
6. Настройка бекапа каналов в случае наличия еще одного провайдера (а о xl0 все и забыли)
7. Разруливание трафика между несколькими каналами средствами ipfw

Наблюдая выводы таких команд, как top, htop, uptime, w и, возможно, других, пользователь наверняка обращал внимание на строку load average:

Одна фирма расположила на колокейшне серверочек для внутренних нужд и сразу купила /30 адреса для соих потребностей. Сконфигурено это было как алиасы (eth0:0, eth0:1 и т.п.). Все работало великолепно, пока по прошествии некоторого времени появилась здравая идея разнести разные сервисы на разные виртуальные машины. Поскольку в качестве хоста использовался Ubuntu Server, то выбор KVM в качестве виртуализатора произошел сам собой. И здесь, и в остальном нете уже немало умных слов было написано по установку и настройку KVM и сетевого окружения, не буду на этом останавливаться, расскажу лишь про маленькие детские грабельки, удобно подложенные со стороны провайдера.

Пару месяцев назад нами (2Товарища и Антон Исайкин) была обнаружена уязвимость, присущая в основном большим интернет-проектам (вроде Рамблера, Мейла, Яндекса, Оперы и пр.). Удалось получить доступ к файловым структурам известнейших сайтов (в общей сложности 3320 сайтов) и в ряде случаев их полные исходные коды.

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

О том, что такое хуки в Wordpress и как их там использовать. Статья молодого Wordpress-специалиста, владельца сайта www.wprecipes.com, из Бельгии.

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

1. Часть ЧПУ (человекопонятный URL)

По сути, слово с дефисами.

Паттерн: /^[a-z0-9-]+$/

О ssh и системных администраторах:

С давних пор *nix системные администраторы используют ssh для удаленного управления серверами.
Некоторые из них делают себе готовые наборы скриптов для обновлений софта, раскладки из репозитория, и так далее.
До определенных размахов бедствия можно обходить парк машин одну за одной. Однако рано или поздно парк машин вырастет до вполне себе солидных размеров и тогда простейшая раскладка по фронтэндам новых скриптов становится головной болью нескольких часов.

Вот здесь вот и начинается самое интересно:
одни системные администраторы запускают свои скрипты в несколько потоков, другие придумывают как отмазаться от части машин.

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

И так узкое место при запуске это загрузка .sqlite, базы данных вашего профиля. При интенсивной работе с Фоксом, базы разрастаются, в них появляются «пустые места», ну и главный недостаток, файл базы данных становится сильно фрагментированными. Для решения подобной проблемы существует специальная команда «очистки», точнее операция пересоздаёт файл базы, но уже без пустых мест. Для этого нужно проделать следующее:

Предисловие

Пост является кратким конспектом Wiki, TechNet'а, FreeBSD'шного handbook'a, Serverfault'a, множества RFC и документов IANA, а также курсов от Специалист.Ру для сотрудников Яндекса.

Пост можно рассматривать как копилку ссылок по актуальной на 2012 год спецификации IPv6. Однако он никак не описывает возможные способы установки IPv6 соединения с интернетом и не привязан к какой-либо определённой ОС.
Учтите, что прочтение данной хабрастатьи займёт у вас не более получаса, однако крайне рекомендуется ознакомиться со всеми приведёнными в статье ссылками… Последнее может занять несколько недель.

Этот пост можно было б начать по разному. Можно по делу: как необходима система мониторинга для поиска ошибок системы и как она помогает обнаружить узкие места. Но, сейчас лето, время отдыха на природе, и начну с того, как я решил узнать, как же часто менятеся прогноз погоды, с помощью популярного средства мониторинга Cacti. Под катом, о любопытный читатель!, тебя ждут рассказы о том как настроить мониторинг произвольных данных в Cacti, да не просто, а с картинками.