Пока мало видел серверов на Skylake, но, скорее всего, в BIOS просто так выключить набор инструкций нельзя. В ход можно пустить маскирование результатов инструкции CPUID (в основном, в виртуализации), либо пересборку ПО без использования этих инструкций.
Комментарии выше верны: PCU «видит» исполнение инструкций AVX и в некоторых случаях (для некоторых инструкций) соответствующим образом снижает частоту. Изменение частоты занимает какое-то время, и даже небольшое число инструкций способно продержать процессор на пониженных частотах довольно долго (в некоторых источниках указывается время реакции на отсутствие AVX команд в 1 мс, что по меркам процессора вечность). В это же время на процессоре исполняется и «обычный» код, который от понижения частоты страдает. А так как как обычного кода в тестах автора подавляющее большинство, то и общая производительность падает довольно значительно.
Автор использовал такую конфигурацию и там accept_mutex явно off в обоих случаях.
Вообще я сам наблюдал описываемый эффект в боевой обстановке (там был NGINX версий 1.9/1.10 и основная нагрузка была в терминировании SSL), но значение accept_mutex не помню.
В выдуманной. Автор статьи имел в виду, что размеры заголовков для IPv6 без Ethernet и для мифического IPv4+ с IP-адресами 64 бита и Ethernet будут одинаковы.
Простите за некрокоммент, но радуйтесь, что у Вас ничего не вышло с GFS2. Эксплуатировал принесённый интегратором криво настроенный GFS2 поверх FC (как ФС, без clvm) для хранения дисков ВМ — боль и страдания. Выкинул и вздохнул свободно. У того же Cinder (по крайней мере на начало 2015 года) довольно сносные драйверы для нарезания LUN-ов в СХД напрямую, можно было попробовать их (если у Вас, конечно, не MSA, драйвер к которому в ту пору то торжественно выкидывался из Cinder, то торжественно вносился обратно). Да и работой multipath в Ubuntu я не очень доволен (фантомные боли при «моргании» путями). В общем, у меня сложилось мнение, что с FC и прочим энтерпрайзом RHEL и его производные дружат значительно лучше просто на том основании, что в Ubuntu это никому не нужно.
В заголовке «сравниваем Moodle и Teachbase», в тексте же «с Moodle мы себя сравнивать не будем – это не вполне корректно». Что же не вполне кооректно: статья или заголовок?
Профессиональная поддержка у Moodle есть, на moodle.com/partners можно выбрать себе поддерживающего по вкусу (правда, когда я был в теме, в РФ было несколько больше зарегистрированных партнёров).
Что же до энтерпрайза — он тоже пользуется Moodle, ровно так же покупает систему с саппортом у партнёра и ещё пачку доработок для интеграции со своими остальными ИТ-системами (мы же про энтерпрайз говорим), как если бы это был продукт с закрытым исходным кодом. OpenSource != бесплатно, у каждого продукта есть стоимоть эксплуатации.
Преподавателю, который только создаёт курсы, а не устанавливает сам Moodle, знать веб-разработку необязательно, а если так хочется неспециалисту в ИТ свой Moodle заиметь — к его услугам разнообразные Moodle хостинги.
я всегда даю ему ID этого багрепорта из нашего внутреннего багтрекера
Я пил неделю (от радости), когда, скажем так, это появилось. Нельзя оставлять клиента с фразой «спасибо за ваше сообщение, это явно баг[, но даже если мы его починим, вы ни за что об этом не узнаете]».
Описание «OpenStack вкратце» местами способно ввести в заблуждение. Keystone практически не занимается авторизацией, и уж тем более не компонентов, а Nova не provision-ит виртуалки самостоятельно. Juno уже вышел, кстати, а Ironic перенесли на Kilo.
OpenStack это конструктор, интерфейс над существущими технологиями виртуализации, хранения данных, предоставления доступа в сеть. Просто так сложилось, что его чаще всего используют в связке KVM + Open vSwitch. API, на мой вкус, довольно кривое, чего стоит одна эпопея с «project» vs «tenant» в терминологии.
Надеяться, что конструктор сам (ну или по щучьему веленью) соберётся в нужную конфигурацию и будет работать, несколько наивно, и советую три раза подумать (и семь раз протестировать), прежде чем разворачивать сие в бой. Теги в посте проставлены правильно.
Из одного из postmortem-ов Amazon (раздел «EBS Software Bug Impacting Snapshots») косвенно следует, что снимки и тома физически удаляются не сразу. Теоретически можно (было) вступить в полемику с поддержкой и добиться от них чего-то на эту тему. Однако, после аналогичного сбоя задав вопрос «окей, вы сделали мне снимок тома, в котором нечитаемые области заполнены нулями; не поделитесь ли смещениями этих утерянных областей?», вразумительного ответа я так и не получил. Благо, спрашивал из чистого интереса и проще оказалось выкинуть том и сделать на его месте новый (все крупные «вылеты» AWS мы переживали очень удачно).
Люди en masse не умеют делать надёжные бекапы, потому что для этого надо быть пессимистом, параноиком и обладать способностью объяснить бизнесу «зачем нам ещё одна копия наших 10Т данных, за которые мы и так платим $1000 в месяц за хранилище и столько же за снимки?». Ну и популярный ныне «release early» — он про фичи, а не про надёжность. Фичу продать легко, а надёжность сложно, потому что люди очень везучи ровно до тех пор, пока они не станут невезучими.
Совет 0. Ваш sh-скрипт должен занимать максимум 2-4 экрана в редакторе. Если скрипт слишком большой — перепишите его на нормальном языке программирования. Perl и Python сейчас есть практически везде (embedded-гусары, молчать!).
Если Вы не можете написать простой и лаконичный скрипт, то это не скрипт. Либо напишите его и никому не показывайте (.bashrc — отличное место, где можно делать всё, что Вам угодно).
Противники этого совета могут попробовать взять на поддержку пачку унаследованных связанных друг с другом sh-скриптов хотя бы в 2 тысячи строк размером и 5 лет возрастом и поделиться ощущениями.
Явный кеш БД, вроде как, оторвали в 2.x, мотивируя это «лучшим» DB слоем? Хранить сессии в базе они сами не рекомендуют в вики (да и их сессии намного дешевле хранить на ФС с каким-либо session stickness в кластере). Запросов на чтение из БД в Moodle в разы (если не на порядки) больше, чем на запись, и в недрах трекера даже есть упоминание, венчающееся «мы что-то где-то как-то протестировали, нам не понравилось».
Я же тоже не просто так написал, я со всем этим реально сталкивался. И те 2.5 Moodle Partner'а, которых я своими глазами видел, либо гасят проблему производительности железом (иногда очень смешно), либо своими собственными разработчиками, которые делают как надо, а не как придётся. Есть, например, забавный тикет, в котором человек спрашивает разработчиков, зачем они раздачу статики от тем оформления запихали в PHP-скрипты. Доводы даже как-то местами понятны, и понятно, что это обходится поставленным впереди прокси-сервером, но ведь это знать надо, что оно вот так-то устроено и вот так-то без последствий лечится.
В своё время я правки в ядро просто по diff-ам от оригинальной версии посмотрел. Но мне было проще — была задача просто определить, можно ли это всё выкинуть без значительного ущерба для функционала.
> Moodle хорош именно как интеграционная платформа: достаточно стабилен, если не ставить экспериментальные версии (больше 60 тысяч инсталляций выявляют большинство проблем раньше, чем вы их заметите), масштабируем (имеются инсталляции более чем с 1 миллионом пользователей)
Всё бы хорошо, но есть нюансы. Выявить-то большинство проблем выявят, но вот когда разработчики их починят — большой вопрос.
Масштабирование «из коробки» практически никакое: нет поддержки read-only slave DB (хотя обещают), нет поддержки X-Sendfile (хотя обещают), по некоторым тикетам напрашивается вывод, что собственно разработчики Moodle нагрузочным тестированием себя не утруждают. На одном и том же сервере инсталляция версии 2.0 по умолчанию ест вдвое больше ресурсов (по времени генерации страницы/данным performance info), чем инсталляция по умолчанию 1.9.
По коду разбросано вдохновляющее количество хардкода (например, максимальное количество недель в курсе и combobox для него на 52 элемента вместо textbox'а с одним числом, период enrollment'а).
В итоге, для реализация масштаба ВУЗа не соглашусь с автором в части «никаких правок в ядре, никаких патчей и хаков». Да, нужно постараться максимально их избежать, но делать их всё равно придётся рано или поздно, ибо некоторые вещи через API недоступны. Так что лучше сразу обеспечить наличие под рукой хоть какого-то специалиста в PHP, который умеет вести документацию на доработки и таскать их от релиза к релизу.
Ну и да, не стоит мне писать, что это OSS, где твой вклад и т.д., ибо я не разработчик. В конце концов, я же не говорю, что хуже Moodle нет, а лишь сожалею, что нет сильно лучше.
Мне тоже не хватало маленьких 64-бит инстансов, ибо теперь не нужно держать по две AMI в регионе для разных размеров инстансов, достаточно только одной. И смена размера инстанса на любой теперь производится простым остановом/запуском — удобно.
К тому же, появилась закрывашка для дырки в оперативной памяти инстанса (1Гбайт — 2Гбайт — дырка — 8Гбайт).
Вообще я сам наблюдал описываемый эффект в боевой обстановке (там был NGINX версий 1.9/1.10 и основная нагрузка была в терминировании SSL), но значение accept_mutex не помню.
Профессиональная поддержка у Moodle есть, на moodle.com/partners можно выбрать себе поддерживающего по вкусу (правда, когда я был в теме, в РФ было несколько больше зарегистрированных партнёров).
Что же до энтерпрайза — он тоже пользуется Moodle, ровно так же покупает систему с саппортом у партнёра и ещё пачку доработок для интеграции со своими остальными ИТ-системами (мы же про энтерпрайз говорим), как если бы это был продукт с закрытым исходным кодом. OpenSource != бесплатно, у каждого продукта есть стоимоть эксплуатации.
Преподавателю, который только создаёт курсы, а не устанавливает сам Moodle, знать веб-разработку необязательно, а если так хочется неспециалисту в ИТ свой Moodle заиметь — к его услугам разнообразные Moodle хостинги.
Я пил неделю (от радости), когда, скажем так, это появилось. Нельзя оставлять клиента с фразой «спасибо за ваше сообщение, это явно баг[, но даже если мы его починим, вы ни за что об этом не узнаете]».
Потом всевластный root в скрипте по крону пишет:
И в итоге некоторые файлы не то, чтобы совсем не удаляются, но удаляются не те, что нужно.
Место для хождения по граблям в статье выделено совершенно правильно, да и аргументом xargs может быть не только rm.
OpenStack это конструктор, интерфейс над существущими технологиями виртуализации, хранения данных, предоставления доступа в сеть. Просто так сложилось, что его чаще всего используют в связке KVM + Open vSwitch. API, на мой вкус, довольно кривое, чего стоит одна эпопея с «project» vs «tenant» в терминологии.
Надеяться, что конструктор сам (ну или по щучьему веленью) соберётся в нужную конфигурацию и будет работать, несколько наивно, и советую три раза подумать (и семь раз протестировать), прежде чем разворачивать сие в бой. Теги в посте проставлены правильно.
Люди en masse не умеют делать надёжные бекапы, потому что для этого надо быть пессимистом, параноиком и обладать способностью объяснить бизнесу «зачем нам ещё одна копия наших 10Т данных, за которые мы и так платим $1000 в месяц за хранилище и столько же за снимки?». Ну и популярный ныне «release early» — он про фичи, а не про надёжность. Фичу продать легко, а надёжность сложно, потому что люди очень везучи ровно до тех пор, пока они не станут невезучими.
Я уж думал, что не доживу.
Если Вы не можете написать простой и лаконичный скрипт, то это не скрипт. Либо напишите его и никому не показывайте (.bashrc — отличное место, где можно делать всё, что Вам угодно).
Противники этого совета могут попробовать взять на поддержку пачку унаследованных связанных друг с другом sh-скриптов хотя бы в 2 тысячи строк размером и 5 лет возрастом и поделиться ощущениями.
Однако, для тысяч серверов приведённое решение мне кажется более подходящим хотя бы потому, что вся аутентификация/авторизация происходит локально.
Я же тоже не просто так написал, я со всем этим реально сталкивался. И те 2.5 Moodle Partner'а, которых я своими глазами видел, либо гасят проблему производительности железом (иногда очень смешно), либо своими собственными разработчиками, которые делают как надо, а не как придётся. Есть, например, забавный тикет, в котором человек спрашивает разработчиков, зачем они раздачу статики от тем оформления запихали в PHP-скрипты. Доводы даже как-то местами понятны, и понятно, что это обходится поставленным впереди прокси-сервером, но ведь это знать надо, что оно вот так-то устроено и вот так-то без последствий лечится.
В своё время я правки в ядро просто по diff-ам от оригинальной версии посмотрел. Но мне было проще — была задача просто определить, можно ли это всё выкинуть без значительного ущерба для функционала.
Всё бы хорошо, но есть нюансы. Выявить-то большинство проблем выявят, но вот когда разработчики их починят — большой вопрос.
Масштабирование «из коробки» практически никакое: нет поддержки read-only slave DB (хотя обещают), нет поддержки X-Sendfile (хотя обещают), по некоторым тикетам напрашивается вывод, что собственно разработчики Moodle нагрузочным тестированием себя не утруждают. На одном и том же сервере инсталляция версии 2.0 по умолчанию ест вдвое больше ресурсов (по времени генерации страницы/данным performance info), чем инсталляция по умолчанию 1.9.
По коду разбросано вдохновляющее количество хардкода (например, максимальное количество недель в курсе и combobox для него на 52 элемента вместо textbox'а с одним числом, период enrollment'а).
В итоге, для реализация масштаба ВУЗа не соглашусь с автором в части «никаких правок в ядре, никаких патчей и хаков». Да, нужно постараться максимально их избежать, но делать их всё равно придётся рано или поздно, ибо некоторые вещи через API недоступны. Так что лучше сразу обеспечить наличие под рукой хоть какого-то специалиста в PHP, который умеет вести документацию на доработки и таскать их от релиза к релизу.
Ну и да, не стоит мне писать, что это OSS, где твой вклад и т.д., ибо я не разработчик. В конце концов, я же не говорю, что хуже Moodle нет, а лишь сожалею, что нет сильно лучше.
К тому же, появилась закрывашка для дырки в оперативной памяти инстанса (1Гбайт — 2Гбайт — дырка — 8Гбайт).