Как работает Stack Overflow — железо

http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/
  • Перевод
Хотелось бы сказать, что Stack Overflow — масштабный проект, но это не так. Я имею ввиду мы добились многого, но я не могу назвать наш проект “большим”, ещё рано. Давайте я приведу в пример некоторые цифры — с какой нагрузкой мы имеем дело сейчас. Срез статистики за 24 часа от 12 ноября 2013 года. Это обычный будний день. Отмечу, что здесь представлена информация только по нашим собственным вычислительным мощностям, без CDN.



Статистика


  • 148,084,883 HTTP запросов к нашему балансировщику нагрузки
  • 36,095,312 из них — настоящие загрузки страниц
  • 833,992,982,627 байт (776 ГБ) HTTP трафика отправлено
  • 286,574,644,032 байт (267 ГБ) трафика получено
  • 1,125,992,557,312 байт (1,048 ГБ) трафика отправлено
  • 334,572,103 SQL запроса по HTTP запросам
  • 412,865,051 запрос до Redis серверов
  • 3,603,418 запросов до обработчика тэгов (отдельный сервис)
  • 558,224,585 мс (155 часов) было затрачено на обработку SQL запросов
  • 99,346,916 мс (27 часов) потребовалось на ожидание ответа от серверов Redis
  • 132,384,059 мс (36 часов) прошло на обработку запросов по тэгам
  • 2,728,177,045 мс (757 часов) работали скрипты ASP.Net


Мне обязательно нужно будет написать пост о том, как мы эти цифры получаем, но данная статистика (кроме трафика) рассчитана только благодаря HTTP логам. Как получилось так много часов за день? Мы называем это магией. Большинство людей называют это “несколько серверов с многоядерными процессорами”, но мы всё списываем на магию. Stack Exchange работает на следующем оборудовании:

  • 4 MS SQL сервера
  • 11 IIS Веб-серверов
  • 2 сервера Redis
  • 3 сервера, занимающиеся обработкой тэгов (абсолютно всё, что касается тегов, например запрос /questions/tagged/c++)
  • 3 сервера ElasticSearch
  • 2 балансировщика нагрузки (реализация HAProxy)
  • 2 свитча (каждый на базе Nexus 5596 + Fabric Extenders)
  • 2 Файервол Cisco 5525-X ASAs
  • 2 Маршрутизатора Cisco 3945


Как вся эта красота выглядит можно посмотреть на первой фотографии (выше).

Мы не просто занимаемся хостингом своих сайтов. Ближайшая стойка — это сервера для виртулизации (vmware) и вспомогательной инфраструктуры, которая не влияет на работу сервиса непосредственно, например машинки для деплоя, контроллеры домена, мониторинг, дополнительная база данных для администраторов и прочее. 2 SQL сервера из списка выше были резервными серверами до недавнего времени — сейчас они используются для read-only запросов, так что мы можем продолжать масштабироваться, не задумываясь о нагрузке на базы данных еще долго. 2 веб-сервера из того списка предназначены для разработки и перифирийных задач, по-этому они потребляют мало трафика.

Об оборудовании


Если мы на момент представим, что что-то произошло и вся избыточность инфраструктуры пропала, то весь Stack Exchange может работать на следующем оборудовании без потери в производительности:

  • 2 SQL сервера (Stack Overflow на одной машинке, всё остальное на другой, хотя мы уверены, что они смогут работать на одном сервере)
  • 2 Веб-сервера (возможно три, но я верю, что будет достаточно и двух)
  • 1 сервер Redis
  • 1 сервер для обработки тэгов
  • 1 сервер ElasticSearch
  • 1 балансировщик нагрузки
  • 1 свитч
  • 1 ASA брендмауэр
  • 1 Маршрутизатор


Нам надо будет попробовать отключить часть серверов специально чтобы проверить на деле. :)

Ниже — средняя конфигурация оборудования:

  • SQL сервера работают на 384 ГБ ОЗУ с файловым хранилищем в 1.8ТБ (SSD)
  • Сервера Redis запускаются на машинках с 96 ГБ ОЗУ
  • Сервера ElasticSearch — 196 ГБ ОЗУ
  • Сервера для обработки тегов требуют самых быстрых процессоров, что мы можем приобрести.
  • Свитчи — 10 ГБит на каждый порт.
  • Веб-сервера ничем особым не отличаются — 32 ГБ ОЗУ, 2 четырёхъядерных процессора и 300 ГБ SSD хранилища на каждый.
  • Сервера, у которых нет сети 2х10Гбит/с (например SQL) подключаются четырьмя соединениями по 1 Гбит/с.


Кажется, что 20Гбит/с — слишком много? Да, например SQL сервера в пик не загружают сеть больше, чем на 100-200 Мбит/с, но не забывайте про резервное копирование, перестроение топологии — это пожет понадобиться в любой момент и тогда сеть будет использована на полную. Такое количество памяти и SSD смогут загрузить этот канал полностью.

Хранилище


В данный момент у нас примерно 2 ТБ данных в SQL (1.06/1.16 ТБ на первом кластере из 18 SSD и 0.889/1.45 ТБ на втором, состоящем из 4 SSD). Возможно, стоило бы задуматься об облаках, но сейчас мы используем SSD и время записи в базу равно буквально 0 миллисекундам. С базой данных в памяти и двумя уровнями кеша перед ней, Stack Overflow имеет соотношение чтения к записи 40 к 60. Да, всё верно, 60% времени работы базы данных она пишет.
На веб-серверах используются SSD диски на 320 ГБ в RAID1.
Сервера ElasticSearch тоже снабжаются SSD дисками на 300 ГБ. Это важно, так как там часто выполняется перезапись и индексация.

Мы так же не упомянули о SAN. Это DELL Equal Logic PS6110X с 24 SAS 10K дисками и подключением 2х10 Гбит/с. Используется он как хранилище для виртуальных серверов VmWare как облако и не связан с самим сайтом. Если этот сервер упадёт, сайты некоторое время даже не будут знать об этом.

Что дальше?


Что мы будем с этим делать? Мы хотим большей производительности — это очень важно для нас. 12-го ноября страница загружалась в среднем 28 миллисекунд. Мы стараемся поддерживать скорость загрузки не дольше 50 миллисекунд. Вот средняя статистика загрузки популярных страниц в этот день:

  • Страницы вопросов с ответами — 28 миллисекунд (29.7 млн. запросов)
  • Профили пользователей — 39 миллисекунд (1.7 мил. запросов)
  • Список вопросов — 78 миллисекунд (1.1 млн. запросов)
  • Домашняя страница — 65 миллисекунд (1 млн. запросов), что очень медленно. Мы исправим это в ближайшее время.


Мы мониторим скорость загрузки путём записи таймингов. Благодаря этому, мы можем составить очень наглядный график:


Масштабируемость в будущем


Очевидно, что все сервисы сейчас работают на низкой нагрузке. Веб-сервера потребляют в среднем 5-15% процессора, 15,5 ГБ ОЗУ, и 20-40 МБит/c полосы сети. Средняя загрузка процессора сервера базы данных — 5-10%, 365 ГБ ОЗУ и 100-200 МБит/с полосы сети. Благодаря этому мы можем полноценно развиваться и, что очень важно, мы страхуемся от падения на случай повышения нагрузки — ошибка в коде или любой другой сбой.

Вот скриншот из Opserver:



Главная причина того, что нагрузка настолько низкая, заключается в эффективности кода. Пусть пост и посвящен другому, но эффективный код — критическое место для масштабирования вашего железа в будущем. Все, что вы сделали, но не должны были делать, будет вам стоить дороже, чем если бы вы этого не сделали вовсе — аналогичное правило касается и неэффективного кода. Под стоимостью понимается следующее: энергопотребление, стоимость железа (потому что вам нужно больше серверов, или они должны быть мощнее), разработчики, занятые попытками осознать более сложный код (хотя, честно говоря, оптимизированный код не обязательно становится проще) и скорее всего медленный рендер страниц — что выражается в реакции пользователя, который не станет ждать загрузки еще одной страницы… а то и вовсе больше не зайдет к вам. Цена неэффективного кода может оказаться гораздо выше, чем вам кажется.

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

Подробнее
Реклама
Комментарии 72
  • +12
    В даннй момент у нас примерно 2 ТБ данных
    и 1ТБ оперативки. Решение очень даже понятное.
    Молодцы. Качественный код само собой экономит железо.
    • 0
      Кстати интересно, а какая часть из этого логи? Может так оказаться, что как раз половина. Тогда фактически все живые данные в оперативе.
      • +1
        Да, их архитектура — хороший пример того, как делать не надо, и что получается с архитектурой при узости кругозора и отсутствии актуальных знаний.

        На самом деле, особой проблемы в 1Tb оперативной памяти нет — 30 сверхдешёвых 1-юнитовых серверов с 32Gb памяти (или 60 — с 16Gb) не стоят почти ничего. Большая проблема в том, что даже при условии работы с таким количеством оперативной памяти, их приложение никак не масштабируется, что вынуждает их покупать сверхдорогие сервера с сотнями Gb памяти и сильно ограничивать функционал.

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


          Да что вы? Просвятите нас как надо.

          Малое количество дорогих серверов выгоднее с точки зрения лицензирования и оверхеда. Кроме того мне кажется что их 10 дороги серверов не сильно дороже 30 дешевых. А с учетом лицензирования дешевле на порядок.
          • 0
            Можно начать с того, что не использовать лицензирование, которое, если верить вашим словам, может стоить значительно дороже железа. Я, конечно, не специалист по решениям от Microsoft, но google услужливо подсказывает, что Windows Server 2012 Foundation (вполне годный на небольшие сервера) стоит меньше $100, а Windows Server 2012 Standard стоит раз в 10-15 дороже; аналогично, MS SQL лицензируется пропорционально количеству ядер.

            Если серьёзно, при умении пользоваться, внезапно, Linux оказывается ничем не хуже Windows (кроме проприетарных технологий типа C#), PostgreSQL ничем не хуже MS SQL, да и программировать можно не только для .NET.

            Что касается «как надо» — надо так, чтобы решение оптимально решало бизнес-задачи. Если решение требует несравнимо больших капиталовложений, весьма ограниченно и очень дорого масштабируется и делает добавление ресурсоёмких фич аналогично ограниченным и крайне дорогим — это, очевидно, плохое решение.
            Конкретно в данном случае, возможности шардинга при грамотной архитектуре особо не ограничены, поскольку вопросы, ответы, комментарии, голоса и авторы могут храниться даже в нормальном key-value хранилище, а решений для их индексации по всем интересующим выборкам более чем достаточно.

            PS Спасибо за минус, это лучший способ поддержки дискуссии!
            • +3
              Ключевое слово тут — Failover. Это требует Enterprise лицензий как на Windows, так и на SQL Server.
              Кстати хороший failover на *nix+mysql\postgres стоит тоже немало, но работает обычно хуже и\или сложнее в настройке.

              Шардинг обычно более дорогой, чем scale up, вот только не все СУБД умеют хорошо делать scale up.

              Конкретно в этом случае в SO делаются JOINы. Это позволяет оптимизировать время работы SQL и Web серверов. Там где джоины работают плохо (читай операции с тегами) уже работает отдельный middleware, тяжелые джоины кешируются в redis.

              Если хранить это все в key-value, то надо как-то делать эти джоины. Готовые решения по индексации почти всегда не дают acid транзакционности, что усложняет код. Дополнительное железо понадобилось бы обеспечения транзакционности. И много подводных камней.

              Читай тут — highscalability.com/blog/2009/8/5/stack-overflow-architecture.html, раздел «NoSQL is Hard».

              ЗЫ. Я минусы не ставлю.

              • –1
                Failover можно без особых проблем реализовать на уровне приложения. Хороший failover для mysql/postgres называется master-slave репликация (для особо важных случаев — синхронная), для особо ленивых — на уровне приложения или middleware. Настраивается просто, работает эффективно.

                Шардинг можно делать на уровне приложения или middleware — это избавляет бд от неумения эффективно горизонтально масштабироваться.

                Джойны, конечно, штука нужная и удобная, но на практике неэффективная для Big Data. Данные можно денормализовывать под запросы, можно «джойнить», «доставать данные по индексам» итд на уровне приложения или middleware.

                Что касается ACID, практически всегда consistency не нужно (достаточно eventual consistency), как и, с оговорками, не нужна атомарность, и в этом случае оно реализуется даже простейшими распределёнными блокировками, без транзакций. Подводные камни, конечно, есть, но они многими решены, и в этом нет ничего супер-сложного и уникального — обычная инженерная работа.

                Что касается вашей ссылки, помимо весьма ограниченного подхода, она написана больше 4 лет назад, когда NoSQL решений было заметно меньше, и многие не были достаточно хорошо сделаны для production-использования.

                PS Значит, по хабру ходит маньяк — фанат ограниченных проприетарных решений.
                • +1
                  Судя по тестам синхронная репликация на postgres тормозит, вернее ТОРМОЗИТ. На уровне приложения failover делать неудобно, сильно усложняет приложение. Middleware — усложнение ещё сильнее.
                  Работа программистов, которые вынуждены этот middleware поддерживать, оказывается дороже, чем лицензиии, и сильно дороже, чем железо.
                  Читай тут: www.codinghorror.com/blog/2008/12/hardware-is-cheap-programmers-are-expensive.html

                  Как я уже говорил — шардинг дороже scale up. Поэтому скорее наоборот — шардинг это решение, когда scaleup невозможен. Но шардинг автоматически добавляет проблемы с джоинами, и снова нужно писать (а потом поддерживать) код, который будет имитировать функции MSSQL.

                  Несмотря на то, что ссылка 4-летней давности, проблемы актуальны и сейчас. Инженерные проблемы в общем случае не решены и некоторые нерешаемы вообще. Они решены в частных случаях конкретных систем. Адаптировать их — тоже работа, которую надо делать и код потом поддерживать.

                  NoSQL is hard сейчас не менее чем 4 года назад, и люди в stackoverflow это прекрасно знают и не связываются с этим.

                  ЗЫ. SO это не big data, даже не близко. Тем не менее до масштаба SO доживет один стартап из миллиона.

                  • 0
                    Судя по выводам, вы не разбираетесь в технологии, тесты которой смотрите. Pgpool-II — надёжное и эффективное решение для синхронной репликации.

                    Железо, конечно, дешевле программистов, но вы упускаете тот факт, что SO сами пишут, что для того чтобы их приложение нормально работало даже на их серверах-монстрах, им приходится серьёзно оптимизировать производительность, в том числе поскольку стоимость сервера при scale up растёт совсем не линейно, и старые сервера надо куда-то девать. При работе с шардингом такой проблемы нет; более того, в ряде случаев можно выкладывать совсем неэффективный код и оптимизировать позже по факту наличия потребностей и ресурсов на это.

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

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

                    Если же действительно нужны транзакции, очень хочется джойнов, или просто хочется работать с привычными инструментами, всегда можно шардить MySQL или PostgreSQL, и там уже иметь всё что нужно. Это не сложно, это не создаёт значительных сложностей в поддержке, для этого есть готовые решения, и оно эффективно. Конечно, решение не полностью заменяет единую базу, но на действительно больших объёмах данных выборки не по основному ключу можно делать снаружи (например, в единой базе данных, для выборок по тегам/разделам/рейтингу), и это тоже несложно.

                    Про нерешённость проблем, посмотрите доклады на VLDB, некоторые доклады на Highload++ и прочие специализированные мероприятия — люди успешно решают «нерешённые проблемы», и рассказывают об этом тем, кто готов слушать.
                    Например, если верить вашим словам, у SO есть «нерешённая проблема» — приходится часто делать длительный даунтайм сервиса для обслуживания.

                    PS У стартапов другие проблемы — при такой архитектуре они при скачкообразном росте нагрузки внезапно упираются в сервер, и вынуждены вкладывать значительные деньги в покупку нового, потому как сервера-монстры с большим количеством процессоров и памяти мало у кого можно арендовать, а стоимость облаков минимум в разы выше.
                    • 0
                      Синхронная репликация — не failover. Это часть решения, но не все. Полное failover решение изкаропки имеет MS SQL и Oracle. Остальные СУБД требуют дополнительных компонент и\или поддержку на уровне приложения.

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

                      Любые затраты на разработку не явлюятся единоразовыми. Любой код требует поддержки. Особенно инфраструктурный, так как он зависит от внешних систем, которые постоянно развиваются.

                      Джоины нужны. Вся теория применения NoSQL говорит о том, что надо правильно построить структуру документа (читай заранее придумать все джоины). В SQL такой проблемы нет, так как джоином можно вытащить любое поддерево данных. Вот только такое вытаскивание требует ссылочной целостности, которое в свою очередь требует согласованности изменений. Поэтому NoSQL рулит в очень ограниченных сценариях, а SQL практически во всех. Там где не хватает SQL можно прикрутить кеш, полнотекстовый индекс или свой middleware, обычно этого хватает для очень масштабных проектов.

                      Шардинг SQL баз мешает джоинам. Вот в SO несколько сущностей: посты, комменты, пользователи. По какому ключу шардить? По пользователям? Тогда как собрать ленту новых постов? По постам? тогда как показать все посты пользователя? Денормализация и middleware скажете, так это усложнение на порядок на ровном месте, а выигрыш какой?

                      Денормальзация увеличивает количество код примерно в 3 раза. Начинать с этого нельзя в принципе. Для оптимизации надо не о денормализации думать, а о грамотном кешировании.

                      Я смотрел доклады на HiLoad — там решают проблемы, которых почти не возникает со взрослыми БД и нормальными платформами.

                      SO делает даунтайм раз в месяц примерно, но обслуживание серверов случается гораздо чаще. Потому что у них failover таки нормальный.
                      • +1
                        > Кстати хороший failover на *nix+mysql\postgres стоит тоже немало, но работает обычно хуже и\или сложнее в настройке.

                        > Полное failover решение изкаропки имеет MS SQL и Oracle. Остальные СУБД требуют дополнительных компонент и\или поддержку на уровне приложения.

                        Есть mysql xtradb cluster с поддержкой percona.com (если вдруг мануал не осилится -оплачивается только рабочее время, заранее пакет покупать не надо).
                        Так что про то что чего-то там нет в linux — это неправда.
                      • 0
                        facepalm

                        Извините, но у меня возникает такое ощущение что вы из области теоретических архитекторов.
                        Все что вы говорите — то да, все правильно. НО стоит это обычно дороже и архитектуры scale up. А про надежность и говорить нечего. В том смысле что если руки правильные то все работает как положено и падений 0.0001%, но для этого нужно прямые руки, большая/светлая голова и куча знаний которые ни за каких докладов не получишь, только собственный опыт. К тому же какая разница сколько будет стоить сервер с кучей GB памяти если он все равно отобьется. Как вы предлагаете кучу дешевых серверов — то как бы не дороже вышло. Маршрутизаторы на FC не копейки стоят. Плюс куча серверов — это куча места в DC за которое платить тоже надо. А по лицензиям вообще бред. Откуда вы знаете сколько они там платят, может Cпольски у МС скидку попросил как бывший сотрудник :)
                    • 0
                      Только обычно master-slave делается не для failover, а для скорости. А для failover-а master-master в разных вариациях. Вообще странные вы вещи говорите и про ACID и про атомарность.
                    • 0
                      На Windows уже не требуется Enterprise лицензия, с WIndows Server 2012 ее вообще нет, остались только Standard и Datacenter, которые равны по функциям и отличаются только количеством виртуалок, на которые распространяется лицензия.
                    • +4
                      Стэковые сайты работают на удивление хорошо, зачем придумывать проблемы там, где их нет. Если им подходит и устраивает такая архитектура, то может банально они умеют её готовить? Это же не проект майкрософта, они посчитали во сколько им всё это обходится и их это устраивает. Экономия может оказаться на спичках, если вообще выйдет. Вы ведь никаких цифр не привели чтобы сравнить, просто написали названия продуктов и предположили, что они будут работать не хуже и ещё и бесплатно. Цифры есть? Такой же по нагрузке проект как стековый, сколько всё стоит, сколько поддержка, как оно резервируется и т.д.
                      • 0
                        >зачем придумывать проблемы там, где их нет

                        Например, потому что вы можете не видеть этих проблем, или они могут считать их неразрешимыми. Даунтаймы для обслуживания, высокие требования к эффективности работы кода и sql-запросов, трудность в добавлении ресурсоёмких фич — это всё те вещи, которых вы не увидите (кроме даунтайма). У них действительно большая команда для сервиса с объективно не очень большим количеством фич, и не быстро изменяющимся — это тоже может быть проблемой.

                        Цифры можно приводить только под конкретные требования и ресурсы. Те продукты, с которыми я работаю, заведомо не помещаются в scale up архитектуру, кратко моё мнение относительно сложности работы со scale out архитектурой в комментариях выше.
                        • +2
                          Посмотри оригинальный пост и комменты.

                          Команда инженеров не просто маленькая, очень маленькая.

                          Даунтаймы у них не проблема вообще, плановые даунтаймы у них случаются раз в месяц, три девятки они держат, при этом умудряются использовать edge технологии, вроде CTP версий MS SQL.

                          Количество фич на SO просто зашкаливает, сравнимо с соцсетями, на порядок больше чем у твиттера.

                          ЗЫ. С какими же продуктами ты работаешь, что scale up для них недоступен? Приведи цифры по количеству запросов и объемам данных.
                      • 0
                        PostgreSQL ничем не хуже MS SQL, да и программировать можно не только для .NET.

                        Есть же Mono и у него сейчас уже очень неплохая производительность.
                        • –2
                          > кроме проприетарных технологий типа C#

                          en.wikipedia.org/wiki/Mono_(software) — читаем, прежде чем городить чушь.

                          • –2
                            Свидетели Столлмана, есть что по делу сказать, или только минусить по-тихому умеете? :)
                      • 0
                        Считать что серверы с 350Gb памяти это дорого — заблуждение. Такое количество памяти сейчас поддерживается любым коммодити сервером. Пример: www.supermicro.com/products/system/2u/2027/ssg-2027r-e1r24n.cfm
                        • –1
                          Спасибо за замечание, вы абсолютно правы. Проблема в том, что для того, чтобы сервер смог эффективно пользоваться таким количеством памяти, ему может понадобится 8 процессоров по 4-6 ядер, серверу потребуется высокопроизводительный raid с multipath io, 10Gbps сетка и прочие страшные вещи.
                          • 0
                            Для любой РСУБД чем больше памяти, тем лучше. Все операции чтения с диска кэшируются в памяти и повторные чтения страниц не производятся. Фактически для максимально быстрой работы объем ОП должен быть не меньше объема активных данных (к которым происходят регулярные обращения).

                            Это кстати совершенно не зависит от процессоров и сети.

                            Про скорость диска полностью аналогично, ведь кроме запросов на чтение есть еще и запросы на запись. Чем быстрее диски, тем выше скорость работы СУБД (для нормальных субд), независимо от памяти и процессора.

                            Поэтому в зависимости от workload имеет смысл вкладывать ровно в то, что принесет максимальный прирост.

                            Только вот когда scale up не поддерживается, а доступен только scale out, приходится покупать все вместе: если нужно 360гб памяти, то придется купить 12 серваков по 32гб, а они будут иметь по 4 ядра, итого 48, которые в итоге будут бесполезно греть воздух (ибо 48 ядер нагружить на порядок сложнее, чем 360 гб). И каждому еще понадобится по диску прикупить, а то и несколько. Это уже не говоря про сеть, питание и охоаждение.

                            Еще раз повторю — scale out менее экономичный подход, чем scale up. Это только в облаках scale out — подход по умолчанию, а scale up очень ограничен. Облачные провайдеры используют недорогое commodity железо, поднимая деньги на том что перепродают тебе его. Они не считают совокупные затраты на приложение, а в SO считают.
                            • +1
                              Для того, чтобы сервер эффективно смог поддерживать такое количество памяти, необходимо в него установить эту память и 2 CPU (любых серверных, стоимостью от 8000 рублей каждый), чтобы вся память была видна. Все остальное (raid, 10G и прочее) к делу не имеет никакого отношения, это зависит от конкретных задач.

                              >ему может понадобится 8 процессоров по 4-6 ядер
                              Я говорю о commodity серверах с LGA 2011 сокетом под серверные Intel Xeon'ы (которые чуть менее чем полностью владеют commodity рынком) и которых можно установить лишь 2 (два) на материнскую плату, вон выше даже модель конкретную привел. 2 процессора на плату для них — это технологическое ограничение. О каких магических 8 процессорах по 4-6 ядер говорите вы мне представить сложно.

                              Еще раз повторюсь: сотни гигабайт памяти сейчас — это будничная реальность commodity железа.
                          • +4
                            Как можно обвинять создателей stackoverflow в узости кругозора и отсутствии знаний? Спольски и Этвуд. Не считая остальных очень умных ребят из их команды. Они построили знаковый сайт входящий в топ60 самых посещаемых, никогда не имели особых проблем с надежностью(по-моему стэк лежит реже чем разные облака), без проблем росли и масштабировались. Работает это все без огромных железных затрат, а могут всё это запустить вообще с пары-тройки серверов и при этом всё работает очень быстро. Какие вообще претензии?
                        • 0
                          Интересно, как часто (и сколько в час / день / неделю) выходят из строя SSD.
                          • +16
                            Такой информации от них нет, но по своему опыту скажу, что SSD — не страшно. На своих проектах сейчас используется 34 SSD диска — за пол года не было проблем. Грузятся они не столько на скорость записи/чтения, сколько на IOPS. При этом, диски — бюджетные интеловские (320-е в основном).
                            • 0
                              Сервера своей сборки или берете готовые предложения?
                              • +1
                                Сервера с SSD — все в аренде.
                              • 0
                                SSD в рэйде или это суммарное количество серверов с SSD дисками?
                                • +1
                                  слышал инфу от перконы что некоторые очень бюджетные диски вылетают после 2-3-ёх месяцев работы. но это в случаи максимально интенсивного использования и очень бюджетных решений.
                                  • +1
                                    Так что мешает оценить уровень записей и сделать выводы?
                                • 0
                                  Ресурс MLC SSD по порядку величины это сотни терабайт записанной даты, а от чтений они не портятся. Так что если не хранить на SSD волатильные данные (логи/своп) — они будут жить почти вечно.
                                • 0
                                  Очень интересно. Спасибо за наводку!
                                  • 0
                                    36,095,312 из них — настоящие загрузки страниц

                                    Но 23 млн 12 ноября на www.quantcast.com/p-c1rF4kxgLUzNc
                                    • +3
                                      Это нормально. quantcast, как и многие другие JS счётчики, дают только примерную оценку, которая обычно немного занижена за счёт того, что не все обрабатывают JS. Например, большинство спайдеров и скрейперов не учитываются этими счётчиками, а сервер такой запрос обрабатывает.
                                      Поэтому и получается, что логи сервера будут показывать больше.
                                    • +8
                                      12-го ноября страница загружалась в среднем 28 миллисекунд. Мы стараемся поддерживать скорость загрузки не дольше 50 миллисекунд.

                                      Все таки здесь речь, видимо, о рендере страницы на сервере, а не времени загрузки у пользователя — 50 миллисекунд в абсолютном большинстве случаев не хватит даже для того, чтобы соединиться с сервером и загрузить голый html, а там еще, примерно, 3 десятка запросов.
                                      • +1
                                        разноцветные кабели питания, какая прелесть!
                                        • +15
                                          По ним идёт разноцветный ток.
                                          • –1
                                            Синие воткнуты только с права. Скорее всего это основная и резервная линии питания.
                                          • 0
                                            И цвета такие патриотичные. =)
                                          • +1
                                            Отличный проект и отлично заменяет метод научного тыка.
                                            • +35
                                              А когда StackOverflow падает, как они узнают, как его поднять? (с)
                                            • 0
                                              148,084,883 HTTP запросов до нашего балансировщика нагрузки

                                              Вы хотели сказать «к нашему баланировщику»?
                                              • 0
                                                Да, так будет корректнее. Спасибо.
                                              • 0
                                                Хмм, а что у них такого случилось с августа по октябрь? На последнем графике там рост в разы.
                                                • +1
                                                  Было бы намного интереснее и полезнее посмотреть на схему архитектуры.
                                                  Что-нибудь вроде такого blog.serverfault.com/2011/09/30/the-stack-exchange-architecture-2011-edition-episode-1/ или такого blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/
                                                  Есть такая информация?
                                                  image
                                                  • 0
                                                    4 MS SQL сервера
                                                    11 IIS Веб-серверов

                                                    Интересно, почему выбор пал на Windows решение?
                                                    • 0
                                                      У них основатель в Микрософте работал, насколько помню. Мне больше интересно зачем им ASA и как физически идет пакет из внешней сетки до веб-сервера.
                                                      • 0
                                                        Идейный лидер — Joel Spolsky, действительно работал в MS, будучи Program Manager в команде Excel. С тех пор люто ненавидел MS, managed платформы и взрослые РСУБД.

                                                        Где-то читал что как раз Джоэл хотел сделать проект на RoR, его переубедили использовать .NET. Как раз в тот момент появились ASP.NET MVC и Linq2SQL, которые обладали функционалом не хуже RoR.
                                                        • 0
                                                          И в конце концов пришлось таки ставить серверы с линуксом под Redis.
                                                          • 0
                                                            Ну правильно. Лицензии — основная статья расходов, после ФОТ. Зачем для кешей покупать лицензии Windows если никакого value added нету.

                                                      • 0
                                                        Есть версия что из-за Linq2SQL. Это позволило быстро и качественно сделать Data Access и стартануть буквально на одном серваке.
                                                        • 0
                                                          Возможно сначала так и было. Но где-то видел что Data Access Layer у них сейчас полностью самописный.
                                                          • 0
                                                            Примерно 2 года назад они перешли на code.google.com/p/dapper-dot-net/, до этого были на Linq2SQL с самого начала (более трех лет).

                                                            Надо не забывать что большую часть страниц SO отдает честно бегая в базу, поэтому именно Data Access они оптимизируют до невозможности. Linq2SQL медленно строит запросы и небыстро мапит на объекты. Dapper использует текстовые запросы и делает очень быстрый мапинг.

                                                            Кстати начать с dapper было бы практически нереально. Так как текстовые запросы убили бы продуктивность программистов.
                                                        • +9
                                                          Как же, наверное, линуксоидам не по себе от этой информации.
                                                        • +1
                                                          А, собственно, почему бы и нет? Особенно если отбросить политику.
                                                          Собсно ASP.NET MVC + Linq2DB очень неплохи для стартапа. Ну и как показывает нам статья — вполне себе и для более чем «взрослого» приложения.
                                                        • 0
                                                          А что за система мониторинга?
                                                          Чем строите графики?
                                                        • 0
                                                          Растолкуйте пожалуйста — как правильно понять первые две цифры:

                                                          148,084,883 HTTP запросов к нашему балансировщику нагрузки
                                                          36,095,312 из них — настоящие загрузки страниц


                                                          Правильно ли я понимаю что в IIS лог за день попало 36 млн. записей?

                                                          Но что тогда означает первая цифра и почему она настолько больше?
                                                          • +1
                                                            Насколько я понимаю HAProxy это еще и reverse proxy, который отдает из кеша страницы для не аутентифицированных пользователей.
                                                          • –1
                                                            >В даннй момент у нас примерно 2 ТБ данных в SQL (1.06/1.16 ТБ на первом кластере из 18 SSD и 0.889/1.45 ТБ на втором, состоящем из 4 SSD). Возможно, стоило бы задуматься об облаках, но сейчас мы используем SSD и время записи в базу равно буквально 0 миллисекундам

                                                            Возможно уже давно пора было задуматься о переносе базы с локальных винтов на внешнюю SAN хранилку, не?
                                                            • 0
                                                              Почему на обработку тегов требуются такие большие ресурсы?
                                                              • +1
                                                                Тут смотря с какой стороны посмотреть, 3 сервера из 25 — это не такие уж и большие ресурсы.

                                                                Плюс очень удобно в плане масштабирования — так как они могут наращивать отдельно web, sql, tags сервера не зависимо друг от друга.
                                                              • 0
                                                                Очень интересная статья на стеке MS + чучуть *nix.
                                                                Какие именно версии .NET Framework, Windows, MS SQL вы используете?
                                                                Почему не SphinxSearch и не MongoDB?
                                                                Планируете ли переходить на Mono в будущем?
                                                                Посмотреть бы на программную архитектуру с мапом на железо…

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