Добрый день, хабрачитатели!
Как мы уже ранее писали, 9 августа состоится конференция по высоким нагрузкам High Performance Conference.
Количество полученных заявок и ваши мотивационные письма показали, что данная тема интересна широкому кругу читателей, поэтому… онлайн трансляции быть!
Читать полностью »
Во всем мире подозревают, что лучшие разработчики, архитекторы, системные администраторы и другие IT-специалисты родом из России.
Было создано много крутых highload проектов, но, к сожалению, сейчас у нас нет комьюнити, где бы мы могли постоянно собираться, общаться и делиться опытом.
С другой стороны у нас очень многие любят писать свои «велосипеды», а не использовать уже готовые решения, которые позволяют сильно сократить время на разработку и внедрение.
Поэтому мы решили постепенно исправлять данную ситуацию:
ITmozg.ru организует конференцию по высоконагруженным системам High Performance Conference.
Своим опытом будут делиться Гуру, которые не понаслышке знают о высоких нагрузках:
Даже у таких монстров облачной индустрии, как Amazon случаются проблемы с оборудованием. В связи с недавними перебоями в работе US East-1 датацентра, данная статья может быть полезной.
Варианты построения высокодоступных систем в AWS. Преодоление перебоев в работе
Отказоустойчивость является одной из основных характеристик для всех облачных систем. Каждый день множество приложений проектируются и разворачиваются на AWS без учета этой характеристики. Причины данного поведения могут варьироваться от технической неосведомленности в том, как правильно спроектировать отказоустойчивую систему до высокой стоимости создания полноценной высокодоступной системы в рамках сервисов AWS. В данной статье освещается несколько решений, которые помогут преодолеть перебои в работе оборудования провайдеров и создать более подходящее решение в рамках AWS инфраструктуры.
Для работы типичного Интернет приложения состоит из следующих уровней: DNS, Load Balancer, веб сервер, сервер приложения, база данный, кэш. Давайте возьмем этот стек и подробно рассмотрим основные моменты, которые необходимо учитывать при построении высокодоступной системы:
Хорошо известна старая поговорка, гласящая, что Интернет был создан для порнографии. Увеличение скорости соединения по всему миру, онлайн-вещание видеороликов, видеочаты и живое общение, оптимизация трафика, огромные хранилища и безотказный хостинг — всё это лишь следствия запросов порноиндустрии.
Согласно отчету принадлежащей Google рекламной сети DoubleClick, которая отслеживает посетителей по cookies, в числе 500 самых посещаемых сайтов сети есть десятки порнографической направленности. Xvideos, самый крупный порносайт мира, получает 4,4 миллиарда просмотров страниц в месяц, что в три раза больше, чем CNN или ESPN, и в два раза больше, чем Reddit. LiveJasmin, YouPorn, Tube8 и Pornhub — огромные веб-сайты, посещаемость которых ниже лишь гигантов уровня Google или Facebook.Читать полностью »
Делаю полностью статичный сайт. На самом деле, php выполняет роль бэкенда: если html файла нет, то сгенерировать его и положить в кэш, а далее nginx отдает html файл из кэша сразу, не трогая php вообще.
Сайт должен получиться огромным. Покрайней мере, я сразу стараюсь делать из расчета на высокую нагрузку. И на данный момент, когда php выполняется лишь единожды для генерации страницы, теперь самое узкое место — это отдача уже готовых статичных html файлов.
Следует знать, что при обращении к файлу он помещается в кэш в оперативной памяти ядром системы, и поэтому, как многие думают, заранее хранить статику в каком-нибудь tmpfs нет смысла, совсем. memcached же именно это и делает, и по какой-то причине все его нахваливают, и особенно любят использовать для кэширования html страниц.
Я убедился в обратном и хочу поделиться с вами, что хранить кэш html страниц в memcached не стоит, и какая есть ему лучшая альтернатива.Читать полностью »
Современный сервер – это электронное устройство, где движущихся механических частей почти нет. Почти – потому что жесткий диск, например, ярко выделяется в этом ряду.
Всё это в некоторых случаях можно заменить на одно компактное устройство
При передаче информации между электронными компонентами сервера технологическим пределом является скорость света. Жесткий диск же не может крутиться неограниченно быстро, и его скорость упирается в механику. Следовательно, скорость обработки информации им в сотни и тысячи раз медленнее, чем в процессорах и памяти. Читать полностью »
На Хабре было уже достаточно много топиков на тему ЦОД и вычислительных кластеров, но интересно ли Вам, на каком оборудовании работает гигант facebook или, например, Московский Internet Exchange? Что лежит в основе СКИФ—МГУ «Чебышёв» и какие «железки» в своей сети использует Большой адронный коллайдер? Добро пожаловать под кат, как говорится!
Осторожно! Много картинок и текста.
Читать полностью »
Данный пост не будет рассказывать про индексы, планы запросов, триггеры для построения агрегатов и прочие общие способы оптимизации запросов и структуры БД. Так же не будет рассказывать про оптимальные настройки с префиксом innodb_. Возможно прочитав текст ниже вы лучше поймёте смысл некоторых из них. В данном посте речь пойдёт об InnoDB и его функционирование.
В прошлогоднем обзорном посте, посвященном архитектуре Evernote, мы дали общее описание серверов — “шардов”, которые используем и для хранения данных и для логики приложений. Поскольку Evernote — более персональный сервис, чем, скажем, социальная сеть, то мы можем легко разнести данные отдельных пользователей по различным шардам, чтобы обеспечить достаточно простую линейную масштабируемость. Каждая пара таких шардов управляет двумя виртуальными машинами:
Каждая из этих виртуальных машин хранит транзакционные “метаданные” в базе данных MySQL на массиве RAID-1 из пары 300-гигабайтных дисков Cheetah со скоростью вращения шпинделя 15000 rpm. Отдельный массив RAID-10 из 3-терабайтных дисков Constellation (7200 rpm) разбит на разделы для хранения больших файлов текстового поискового индекса Lucene для каждого пользователя. Спаренные виртуальные машины дублируют каждый из этих разделов от текущей основной к текущей дополнительной машине с помощью синхронного DRBD.
Читать полностью »
Есть проект, в рамках которого приходится работать с большим объем данных. В частности есть одна денормализованная таблица, в которой хранятся все актуальные предложения существующих клиентов, а также устаревшие предложения, помеченные is_deleted = 1, ожидающие удаления.
Количество записей в данной таблице до недавнего времени колебалось от 30 до 50 миллионов. Обычный OPTIMIZE даже при таких условиях не всегда срабатывал. Поэтому отец-основатель (Евгений Васильевич aka haron) придумал пересобирать таблицу таким образом: все актуальные (is_deleted = 0) копировались в таблицу с идентичной структурой с добавлением префикса по дате и времени, а когда копирование завершалось, оставалось только удалить исходную таблицу, а новую переименовать в исходную.
Такой подход работал надежно, пока не потребовалось повысить скорость поиска предложений. И тут начинается наша небольшая история.Читать полностью »
