Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
Больше всего меня радует: 83 дней 16 час. 46 мин. 21 сек. Спасибо за наводку про память!
Это вероятно намек на падежи в строке аптайма в админке...? Секунд 30 голову ломал :-)
Нет, я к тому, что он уже перестал падать, как раньше :)
Отвечает Александр Друзь amarao 
Это я чтобы ему уведомление об упоминании пришло, я лично не знаю.
По крайней мере «внутривиртуалочный» дисковый кеш я вижу.
Это я чтобы ему уведомление об упоминании пришло, я лично не знаю.
По крайней мере «внутривиртуалочный» дисковый кеш я вижу.
Точка аккаунтинга — выход из виртуалки. Любое ИО, оптимизированное ядром (кеш, io в tmpfs, block ramdisk, сетевое устройство и т.д.) до хоста не доходит и не оплачивается.
Если IO вышло за виртуалку — дальше это наши проблемы как мы его будем оптимизировать — клиент оплачивает именно запросы. Хостовый кеш у нас отсутствует, поскольку хосты должны быть взаимозаменяемые и зависание хоста не должно делать ничего, кроме ребута виртуалки.
Хотя кешируем, да, там несколько сотен гигабайт ram-кеша для кеша на чтение и flashcache для остального.
Если IO вышло за виртуалку — дальше это наши проблемы как мы его будем оптимизировать — клиент оплачивает именно запросы. Хостовый кеш у нас отсутствует, поскольку хосты должны быть взаимозаменяемые и зависание хоста не должно делать ничего, кроме ребута виртуалки.
Хотя кешируем, да, там несколько сотен гигабайт ram-кеша для кеша на чтение и flashcache для остального.
Поправка по поводу drop caches. Уже давным-давно mod считает cached свободной памятью, то есть не добавляет память по мере роста размера кешей. Отключение постоянного drop_caches не увеличит потребление памяти, но немного сэкономит на прогреве кеша после каждого дропа.
Давным давно когда? До апреля 2012 или после?
Полез в репозиторий, очень нудно бисектом искать. По коммитам — в сентябре 2011 уже было. Собственно, формула там простая:
real_free = meminfo.mem_free + meminfo.cached + meminfo.buffers — swap_used.
real_free = meminfo.mem_free + meminfo.cached + meminfo.buffers — swap_used.
Значит это мистика какая-то, но в биллинге потребление памяти выглядит так:
Февраль 2012 — 438 ГиБ * час
Март 2012 — 399 ГиБ * час
Апрель — начались drop_caches по крону + добавлен 1 процесс в памяти. По графику потребления памяти в статье видно, что уменьшился cache, buffers, unused, увеличился apps — за счет нового процесса. Тем не менее:
Май 2012 — 319 ГиБ * час
Июнь 2012 — 319 ГиБ * час
Февраль 2012 — 438 ГиБ * час
Март 2012 — 399 ГиБ * час
Апрель — начались drop_caches по крону + добавлен 1 процесс в памяти. По графику потребления памяти в статье видно, что уменьшился cache, buffers, unused, увеличился apps — за счет нового процесса. Тем не менее:
Май 2012 — 319 ГиБ * час
Июнь 2012 — 319 ГиБ * час
У вас на графике виден использующийся swap. Использовать его или нет — решать вам, но по нашей логике, если виртуалка выпадает в swap, значит ей не хватает памяти, то есть ей нужен больший запас свободной памяти (занятый своп вычитается из real_free, то есть real_free может быть и отрицательным). Когда мы определяем сколько памяти накинуть, то мы следим за тем, чтобы новая свободная память была в заданных границах, при отрицательном значении мы накидываем больше.
Вообще, наш алгоритм легко контролировать. Формула свободной памяти указана. За вычетом момента «до добавления или удаления памяти» free_bottom<=real_free<=free_top.
Вообще, наш алгоритм легко контролировать. Формула свободной памяти указана. За вычетом момента «до добавления или удаления памяти» free_bottom<=real_free<=free_top.
Логика неиспользования правильная, если производительность превыше всего.
Если скорости достаточно, а своп дешевле памяти — но его использование также может быть логичным, но уже с экономической точки зрения.
Т.е. вы говорите, что у меня до drop_caches количество свободной памяти поддерживалось на уровне большим чем 32Мб, из-за того, что часть программ была в свопе (и свободная память поддерживалась на уровне 32Мб+размер свопа)?
Если скорости достаточно, а своп дешевле памяти — но его использование также может быть логичным, но уже с экономической точки зрения.
Т.е. вы говорите, что у меня до drop_caches количество свободной памяти поддерживалось на уровне большим чем 32Мб, из-за того, что часть программ была в свопе (и свободная память поддерживалась на уровне 32Мб+размер свопа)?
Вероятнее всего.
Кстати, управлять «свопливостью» линукса можно силами самого линукса. en.wikipedia.org/wiki/Swappiness
sysctl vm.swappiness=60
Чем число больше, чем больше Линукс будет запихивать в своп.
Кстати, управлять «свопливостью» линукса можно силами самого линукса. en.wikipedia.org/wiki/Swappiness
sysctl vm.swappiness=60
Чем число больше, чем больше Линукс будет запихивать в своп.
Отличный опыт.
PS: прекрасно, что вы знакомы с немецким, но почему бы не написать привычно, по-русски?
/граммар-наци, на самом деле нет/
PS: прекрасно, что вы знакомы с немецким, но почему бы не написать привычно, по-русски?
/граммар-наци, на самом деле нет/
Насчет немецкого — не знаком я с ним, TF2 во всем виноват :-)
Но с вами склонен согласится.
Но с вами склонен согласится.
Если вы о приставке Über-, то она давно уже стала международной:
en.wikipedia.org/wiki/%C3%9Cber#Current_popular_culture
en.wikipedia.org/wiki/%C3%9Cber#Current_popular_culture
Да, кстати, по поводу «время отставало на 0.5с». Это была очень прелюбопытная история. Когда пришёл тикет о проблеме, я очень удивился, т.к. все хосты намертво на ntp завязаны. В процессе поиска проблемы мы перебрали массу вариантов, настроили нагиос, который теперь ругается, если время уползает более чем на 0.02c на хосте.
За вычетом всех наших предположений о причинах, пока что остановились на следующем: в ходе реформирования сети в определённый момент времени трафик от management (где ntp сервер) до хостов (где ntp-слейвы) шёл через агрегированный (lacp) линк неравной длины, с полуторакратной разницей в latency между линками.
Вероятнее всего это намертво снесло голову бедному ntpd, который так круто поправил drift-файлы, что стал самоубегать после каждой ресинхронизации.
Практически — удалили drift-файлы, прошло.
За вычетом всех наших предположений о причинах, пока что остановились на следующем: в ходе реформирования сети в определённый момент времени трафик от management (где ntp сервер) до хостов (где ntp-слейвы) шёл через агрегированный (lacp) линк неравной длины, с полуторакратной разницей в latency между линками.
Вероятнее всего это намертво снесло голову бедному ntpd, который так круто поправил drift-файлы, что стал самоубегать после каждой ресинхронизации.
Практически — удалили drift-файлы, прошло.
Хороший повод потрясти провайдеров насчет IPv6. Я Билайн уже потряс, они пугаются и молчат.
Кстати только что пришел ответ из Билайна:
В первую очередь приношу Вам искренние извинения за столь длительное ожидание ответа на Ваш запрос. Это связано с большим количеством писем, поступивших на электронный ящик Компании. На текущий момент информации о переводе на ipv6, к сожалению, нет. Со всеми изменениями Вы можете ознакомиться на нашем сайте:
Билайн, насколько я слышал IPv6 даёт только юридическим лицам и то не всем. Раньше они рассказывали, что IPv6 очень плохо дружит с L2TP.
Провайдеров тряси-не тряси, кто умеет, те и так предлагают, кто не умеют… делают умное лицо, и предлагают либо жуткие ценники за IPv6, либо отмазываются, что тема IPv6 не актуальна, ибо мало кто его поддерживает, и, мол, зачем он, такой экзотический?
Ну уж о причинах (1. старое железо/ПО в сети провайдера, 2. неподдержка биллингом провайдера 3. неподдержка железом на стороне клиента 4. малый объем знаний у провайдера 5. опасения, что большое кол-во белый IP добавить клиентам и провайдеру геммороя, 6...) говорить не стоит. Просто, как-то, и в правду, брать деньги за IPv4 сейчас со ссылкой, что IPv6 уже работает, как-то напоминает выкручивание рук, ибо отказаться не могут себе позволить слишком многие.
Ну уж о причинах (1. старое железо/ПО в сети провайдера, 2. неподдержка биллингом провайдера 3. неподдержка железом на стороне клиента 4. малый объем знаний у провайдера 5. опасения, что большое кол-во белый IP добавить клиентам и провайдеру геммороя, 6...) говорить не стоит. Просто, как-то, и в правду, брать деньги за IPv4 сейчас со ссылкой, что IPv6 уже работает, как-то напоминает выкручивание рук, ибо отказаться не могут себе позволить слишком многие.
Мы своего добились — 400 освободившихся IP при 0.3% снижении потребления ресурсов (в общем по облаку), то есть были удалены наименее нагруженные виртуальные машины, менее всего нужные владельцам и лежавшие «про запас». Часть из них перешла на ipv6-only, часть была удалена.
Мы бы рады были бы продолжать обслуживать, но т.к. запас IP фиксированный, то либо мы обслуживаем клиентов, которые нам приносят деньги (проще: мне зарплату), либо даём им отказ со словами «извините, IP закончились». Ситуация простая: мы получили last /22 и больше RIPE NCC нам адресов не даст. Вообще. Никак.
Крутимся с тем, что есть.
Крутимся с тем, что есть.
Для внутренних применений можно и IPv6 использовать (но трафик само собой обычный) )
Планируется, но тут есть проблема того, что трафик на хостах для нас не бесплатный. Эту сеть (с дешёвым трафиком) пускать через inet линк? Или городить отдельный? Или даже делать 10G?
10G не будет бесплатной (особенно с учётом, что не все платить будут), отдельный гигабит как-то пошло, общий гигабит — будут зажимать inet-трафик.
А главное, вопрос: о какого порядка деньгах идёт речь? Ну, там, «у нас 10 ГБ/сутки, мы бы хотели платить за это не 6.4р, а 1р». Или «у нас там 2 ТБ/сутки и мы бы хотели платить не 12т.р./сутки, а меньше».
В первом случае — не интересно даже думать (не того порядка вопрос). Во втором — нужно видеть пример, где и кем это будет использоваться.
У меня в roadmap'е на первую половину 2013 запланировано примерно 4 фичи, которые будут заметны клиентам, ещё 2 находятся на стадии «почти закончили» (остальное внутренее инфраструктурное). Я их, конечно, могу подвинуть в смысле разработки локальной сети, но есть ли смысл?
10G не будет бесплатной (особенно с учётом, что не все платить будут), отдельный гигабит как-то пошло, общий гигабит — будут зажимать inet-трафик.
А главное, вопрос: о какого порядка деньгах идёт речь? Ну, там, «у нас 10 ГБ/сутки, мы бы хотели платить за это не 6.4р, а 1р». Или «у нас там 2 ТБ/сутки и мы бы хотели платить не 12т.р./сутки, а меньше».
В первом случае — не интересно даже думать (не того порядка вопрос). Во втором — нужно видеть пример, где и кем это будет использоваться.
У меня в roadmap'е на первую половину 2013 запланировано примерно 4 фичи, которые будут заметны клиентам, ещё 2 находятся на стадии «почти закончили» (остальное внутренее инфраструктурное). Я их, конечно, могу подвинуть в смысле разработки локальной сети, но есть ли смысл?
по факту — синхронизация между двумя виртуалками. свой личный drbd :)
Голосую за машины с внутренними айпишками.
Используйте ipv6. Он есть и на машинах с ipv4, и на машинах без ipv4. Чем это хуже, чем серые адреса?
Вопрос.
Есть такой способ организации веб-приложения: пачка железных серверов (ну, положим, несколько единиц вначале), которые загружены полностью + немного виртуальных, которые держат остаточную часть текущей нагрузки, масштабируются при пиках и не дают простаивать железу (архитектура приложения достаточно резиновая для этого).
Как такое приложение лучше всего захостить на ваших дедиках + в облаке — в предположении, что внутренний сетевой траффик будет изрядным и критичным к latency. Ну, тут как минимум три случая: траффик между железками, между железками и виртуалками, и внутри виртуалок. Что писать инженерам на тему размещения серверов? Имеет ли сюда отношение ipv6?
Спасибо.
Есть такой способ организации веб-приложения: пачка железных серверов (ну, положим, несколько единиц вначале), которые загружены полностью + немного виртуальных, которые держат остаточную часть текущей нагрузки, масштабируются при пиках и не дают простаивать железу (архитектура приложения достаточно резиновая для этого).
Как такое приложение лучше всего захостить на ваших дедиках + в облаке — в предположении, что внутренний сетевой траффик будет изрядным и критичным к latency. Ну, тут как минимум три случая: траффик между железками, между железками и виртуалками, и внутри виртуалок. Что писать инженерам на тему размещения серверов? Имеет ли сюда отношение ipv6?
Спасибо.
Насчёт сетевого latency ничего капитального обещать не могу. Если по архитектурным причинам нам понадобится долгий путь, он будет долгим. Иными словами, в пределах 500-800 мкс может быть.
Относительно ipv6 на дедиках — вроде бы, сделали (уточните, это не мой отдел).
В остальном каких-то капитальных проблем не вижу.
Относительно ipv6 на дедиках — вроде бы, сделали (уточните, это не мой отдел).
В остальном каких-то капитальных проблем не вижу.
ipv6 на выделенных и коло серверах есть уже давно, даже был пост в блоге. Плюс железные серверы можно объединять в изолированную локальную сеть.
Было бы здорово, если бы была возможность создать машину из существующего свободного диска. Без автоматической установки чистой системы.
Ещё такой баг (или не баг). Создаю машину. Выключаю. Подключаю свободный диск. Потом уничтожаю созданный при создании машины. После этого если попытаться включить машину, то «Не удалось включить машину: Ошибка XAPI». На вкладке Загрузка не получается ничего больше сделать. Пишет «Не удалось сохранить астройки загрузки для машины». В итоге такую машину похоже только уничтожать… Правильная последовательность действий: подключить диск, потом установить его загрузочным, а только потом удалять первый. Хотелось бы, чтобы вышеописанный сценарий как-нибудь обрабатывался, чтобы можно было установить загрузочным второй диск и машина включалась.
И ещё, я знаю, такой клиент как в общем-то вам не нужен, но… Насколько вам накладно, если, чтобы не платить за ip и получить экстремально дешевую машину иногда когда это нужно, я буду каждый раз создавать новую машину, использовать её, а потом уничтожать, чтобы освободился IP адрес?
Ещё такой баг (или не баг). Создаю машину. Выключаю. Подключаю свободный диск. Потом уничтожаю созданный при создании машины. После этого если попытаться включить машину, то «Не удалось включить машину: Ошибка XAPI». На вкладке Загрузка не получается ничего больше сделать. Пишет «Не удалось сохранить астройки загрузки для машины». В итоге такую машину похоже только уничтожать… Правильная последовательность действий: подключить диск, потом установить его загрузочным, а только потом удалять первый. Хотелось бы, чтобы вышеописанный сценарий как-нибудь обрабатывался, чтобы можно было установить загрузочным второй диск и машина включалась.
И ещё, я знаю, такой клиент как в общем-то вам не нужен, но… Насколько вам накладно, если, чтобы не платить за ip и получить экстремально дешевую машину иногда когда это нужно, я буду каждый раз создавать новую машину, использовать её, а потом уничтожать, чтобы освободился IP адрес?
Или какую-нибудь дополнительную услугу динамического IP, который выделяется тогда, когда машина включается. А в выключенном состоянии плата за IP не берется.
За идею спасибо.
Второе — это невозможность выставить загрузочный флаг для дисков после удаления системного диска? Это чистый баг.
Насчёт создания машин — если вы будете оплачивать её установку, то никаких проблем.
Второе — это невозможность выставить загрузочный флаг для дисков после удаления системного диска? Это чистый баг.
Насчёт создания машин — если вы будете оплачивать её установку, то никаких проблем.
Попробовал — управление загрузкой работает после отключения системного дсика. Или я что-то делаю не так?
echo 3 > /proc/sys/vm/drop_caches
неправильно, правильнее:
sync && echo 3 > /proc/sys/vm/drop_caches
неправильно, правильнее:
sync && echo 3 > /proc/sys/vm/drop_caches
Имея облако в качестве шлюза, задумываюсь о смене облака на VDS, тот же первый вдс (первое что выдал гугл) предлагает 150р. Потребление тоже, но плата фиксированная.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Облако Selectel — о супер-хабраэффекте, небольшой оптимизации, и расходах за 2 года