Как умирал Foursquare

4 октября сервис Foursquare ушел в довольно длительный даун. На следующий день компания опубликовала пост-мортем касательно проблем, которые испытывал сервис, разрешив заодно заглянуть в инфраструктуру весьма крупного проекта. Foursquare использует MongoDB в качестве базы данных, которая до этого работала всего на двух серверах в амазоновском EC2. В какой-то момент потребление памяти одним из серверов начало расти бешеными темпами, компания приняла решение расширить MongoDB на третий сервер, однако проблемы с памятью на этом не закончились.

СТО компании 10gen, которая производит и продает коммерческую поддержку к MongoDB (сама база доступна бесплатно), сегодня предоставил подробное описание проблемы:

• Foursquare разбила данные на 200 секторов, и пока масштабирование между двумя серверами происходило по принципу "пятьдесят на пятьдесят"
• MongoDB все держит в памяти, каждый из серверов Foursquare содержал 66 гигов памяти
• Чек-ины пользователей – дело случайное, и в какой-то момент их количество на один из серверов серьезно превысило количество чек-инов на другой сервер
• В какой-то момент MongoDB переросла за 66 ГБ, и начала сохранять данные на жесткий диск, с соответствующим торможением
• Подключение третьего сервера и последующий передел чек-инов должны были помочь, однако
  • все еще требовалось время на миграцию
  • MongoDB упорно не освобождала память – чек-ины от Foursquare весьма миниатюрны (300 байтов в среднем), одна страница оперативки в конфигурации сервера занимала 4КБ, итого даже если базе данных говорили, что какие-то из чек-инов теперь будут обслуживаться третьим сервером, количество оставшихся чек-инов в секторе на 4 килобайта все равно поддерживало его в рабочем состоянии
• Сервис пришлось убить для того, чтобы за 4 часа завершить миграцию нужных чек-инов на третий сервер. После этого на старых серверах MongoDB прогнали repairDatabase(), которая дефрагментировала секторы, освободив нужную память