По тестам от Percona MaxScale медленнее ProxySQL в fast-forward режиме процентов на 10-20%. Учитывая это и то, что нам важна задержка мы решили не тестировать его. В итоге ProxySQL тоже не прошел по задержкам оставив первенство Haproxy. Если у вас есть информация о том, что сейчас ситуация изменилась и MaxScale может обогнать ProxySQL, то мы с удовольствием протестируем его скорость работы.
У нас уже был опыт использования продуктов от Percona, причем вполне успешный. Нас устраивает их скорость выпуска багфиксов и портирования патчей из апстрима. К тому же они русскоязычные и продают поддержку. Если нам понадобится помощь всегда можно купить у них поддержку их продукта.
Во-вторых у них есть некоторые патчи на Galera Cluster, которые делают его поддержку более простой (например strict_mode, который не даст выполнить потенциально опасные операции на кластере).
master-master обязан считать транзакцию завершенной только тогда, когда ее совершили все ноды
Я не уверен как реализовано в MariaDB Galera, но в классическом Galera Cluster и Percona GC это не так. Каждая транзакция валидируется на всех нодах при коммите на отсутствие конфликтов, а репликация самих изменений выполняется уже после коммита.
Противоречит, никто и не спорит. Но если бы все всё делали по логике и здравому смыслу, то мы бы жили в абсолютно другом мире. И не надо думать, что я считаю рабочих дураками, а капиталистов умниками, все они в первую очередь люди. А люди далеко не самые рациональные существа.
Как пример — распад СССР, куча работающих заводов была продана частным лицам, казалось бы даже инвестировать в производство не надо, оно уже у тебя есть. Надо только поддерживать его на плаву и получать постоянный доход с него. Но нет, большинство заводов было закрыто и распродано или разворовано, часть на все тот же металлолом.
Или например все знают, что алкоголизм/наркотики/курение ведут к болезням и возможно скорой смерти, но почему то кучу людей это не останавливает.
Вы сами говорите, что средства производства должны быть в собственности рабочего. Только станок с неба не упадет. Чтобы дать возможность рабочему работать за ним его сначала надо купить, а захочет ли рабочий вкладывать 2-10М рублей в станок, чтобы потом отбивать его стоимость 10 лет?
Есть конечно вариант отобрать станки у злобных капиталистов и раздать рабочим, но к чему то хорошему это вряд ли приведет. Скорее всего станки сдадут на металлолом.
ИМХО сейчас общественный строй достаточно сбалансирован, у тех же рабочих есть возможность уйти работать на завод получше к менее «эксплуатирующему» капиталисту. А если так уж не хочется работать на дядю, то открывать ИП и свое производство. Вот только со своим предприятием приходит куча проблем, никакой гарантированной зарплаты, рабочий не может весь день производить полезный продукт, а вынужден делать тысячу других дел, таких как бухучет, продажа товара, закупка сырья, реклама и тд.
И тут выглядит логичным следующий шаг — делегировать эти обязанности кому то другому и нанять их на зарплату. Oh wait, мы же вернулись к началу, только уже рабочий стал капиталистом.
Офф гарантия — 3.6 перезаписи всего объема накопителя (500 Гб) в день в течение 5 лет. У нас нагрузка должна быть сильно меньше, до 500 Гб в день. С такой нагрузкой скорее контроллер умрет, чем выработается ресурс.
Интересная статья, спасибо. А не могли бы вы посчитать (среднюю, и 95/99 перцентиль) скорость износа SSD с разбиением на серверные и консьюмерские модели?
Тот же хецнер грешит тем, что ставит в дешевые сервера десктопные SSD, причем самые дешевые. У нас их десктопные SSD живут примерно пол года с репликами БД, а ентерпрайзные самсунги уже по 2.5 года работают и умирать не собираются.
а что делать, если туда надо постоянно лазить, править, ну и конечно же нет лога всех действий, не писать же каждый раз cp cfg cfg_back, со временем запутаешься и забьешь на это дело.
Конфиг Haproxy в Ansible, Ansible в гит. И никаких проблем с версионированием изменений. Плюс без проблем разливается на кучу серверов.
Для сбора статистики — экспортер в Prometheus, откуда можно вытягивать данные в Grafana и строить красивые графики.
Ваш подход без сомнения имеет право на жизнь, но по моему описанное выше больше соответствует UNIX-way, т.к. легче масштабируется до десятков-сотен серверов и очень легко умеет в автоматизацию. Накрутить дополнительной логике в Ansible дело нескольких минут, на крайний случай часов, и вот у вас уже есть например авто дискавери бэкендов или автоматическое указание веса бэкенда в зависимости от количества процессорных ядер на нем и все остальное, что вы только сможете придумать. ;)
Касательно GPLv2 — вам стоит прочитать ее внимательно. Согласно лицензионному соглашению исходные тексты обязаны быть предоставлены людям, получившим бинарники системы, тем или иным способом.
Да, я это знаю. Как раз про это была эта часть моего вопроса:
… нужно ли для этого быть вашим клиентом?
Многие просто выкладывают исходники в открытый доступ, но не будучи вашим клиентом я не могу требовать их у вас.
Вы пишите о своих наработках на базе KVM. Отправляете ли вы эти патчи в апстрим и принимают ли их? Можно ли где то у вас на сайте их получить/скачать и нужно ли для этого быть вашим клиентом?
И QEMU и ядро Linux, частью которого является KVM, публикуются под GPLv2, соответственно исходники должны быть;).
С шумом все более-менее нормально, большинство времени кулер выключен. При запуске чего то тяжелого и длительного, например компиляции большого проекта, начинает активно шуметь. Проц прогревается до 78-84 градусов.
Использую ядро 4.16.9, дистрибутив Arch, дрова «xf86-video-intel 1:2.99.917+831+ge7bfc906-1». Проблем из-за 4К пока не видел, но не исключаю, что это из-за свежих версий софта, который я использую. Специально брал ноут только со встройкой Intel, что бы не парится с проприетарными дровами нвидии и не править их глюки.
На просторах интернета куча текстовых и видео обзоров с качественными фото со всех ракурсов, анбоксингом и прочими радостями. Я решил, что вряд ли сделаю обзор внешности ноутбука лучше, чем они и решил сосредоточиться на функциональной части.
Я использовал 175% процентное масштабирование чтобы уменьшить интерфейсы ПО, по мне они часто занимают слишком много места на экране. Таким образом увеличивается размер полезной области экрана.
Ну и конечно качество шрифтов сильно улучшилось, на FullHD 13-ке были заметны отдельные пиксели, с 4к пикселей не видно вообще.
Судя по страничке Speed-and-memory-use libvips быстрее, но должен заметитить, что результаты imlib2 у них конечно немного странные и возможно они что то не докрутили. Более существенный, по моему мнению, недостаток imlib2- странная лицензия и достаточно маленькое комьюнити. Хотя погонять бенчмарк возможно все таки стоит.)
Все запросы с @ в конце отправляются nginx'ом на ресайз бэкенд.
Nginx кэширует ответы бэкенда, и при следующем запросе она отдается уже из кэша, а не с бэкенда. В readme в репе есть пример конфига Nginx, который реализует эту логику.
По поводу ресайза в несколько проходов. Не могли бы Вы рассказать как вы это делали и какой библиотекой? На первый взгляд похоже на проблему с алгоритмом ресайза, из-за которой он при большом изменении размера портил качество. Теоретически вариант, когда мы ресайзим большую в маленькую должен быть лучше, чем вариант, когда мы делаем «большая->средняя->маленькая», т.к. не происходит потери на шаге «большая->средняя».
Естественно, мы так и делаем. В моем коде это работает так:
Вместо "/test.png" в том месте страницы, где нужна маленькая версия мы пишем "/test.png@75". Все запросы с @ в конце отправляются nginx'ом на ресайз бэкенд. Он в свою очередь пасит url, скачивает оригинал ("/test.png"), ресайзит его до нужного разрешения и отдает nginx'у. Nginx кэширует результат и отдает его клиенту.
Не очень понял, что вы имеете в виду под простым случаем. Часть информации мы при ресайзе естественно теряем, но это не должно ухудшать качество картинки «на глаз»(естественно если потом получившуюся картинку не растягивать до размера оригинала).
Если же это проявляется в заметных артефакт, то есть смысл смотреть на алгоритм ресайза и его настройки.
На всякий случай уточню предыдущий коммент: мы храним только оригиналы в максимальном используемом разрешении (200х200 в примере). Менее качественные версии генерируются динамически и только кешируются на некоторое время.
Второй момент: например про главную. 75х75 это размер, определяемый версткой страницы, то есть в верстке есть контейнер 75х75 пикселей и мы вставляем туда версию нужного размера. Мы естественно не вставляем 75 версию в 200 контейнер.
Во-вторых у них есть некоторые патчи на Galera Cluster, которые делают его поддержку более простой (например strict_mode, который не даст выполнить потенциально опасные операции на кластере).
Я не уверен как реализовано в MariaDB Galera, но в классическом Galera Cluster и Percona GC это не так. Каждая транзакция валидируется на всех нодах при коммите на отсутствие конфликтов, а репликация самих изменений выполняется уже после коммита.
Как пример — распад СССР, куча работающих заводов была продана частным лицам, казалось бы даже инвестировать в производство не надо, оно уже у тебя есть. Надо только поддерживать его на плаву и получать постоянный доход с него. Но нет, большинство заводов было закрыто и распродано или разворовано, часть на все тот же металлолом.
Или например все знают, что алкоголизм/наркотики/курение ведут к болезням и возможно скорой смерти, но почему то кучу людей это не останавливает.
Есть конечно вариант отобрать станки у злобных капиталистов и раздать рабочим, но к чему то хорошему это вряд ли приведет. Скорее всего станки сдадут на металлолом.
ИМХО сейчас общественный строй достаточно сбалансирован, у тех же рабочих есть возможность уйти работать на завод получше к менее «эксплуатирующему» капиталисту. А если так уж не хочется работать на дядю, то открывать ИП и свое производство. Вот только со своим предприятием приходит куча проблем, никакой гарантированной зарплаты, рабочий не может весь день производить полезный продукт, а вынужден делать тысячу других дел, таких как бухучет, продажа товара, закупка сырья, реклама и тд.
И тут выглядит логичным следующий шаг — делегировать эти обязанности кому то другому и нанять их на зарплату. Oh wait, мы же вернулись к началу, только уже рабочий стал капиталистом.
Тот же хецнер грешит тем, что ставит в дешевые сервера десктопные SSD, причем самые дешевые. У нас их десктопные SSD живут примерно пол года с репликами БД, а ентерпрайзные самсунги уже по 2.5 года работают и умирать не собираются.
Конфиг Haproxy в Ansible, Ansible в гит. И никаких проблем с версионированием изменений. Плюс без проблем разливается на кучу серверов.
Для сбора статистики — экспортер в Prometheus, откуда можно вытягивать данные в Grafana и строить красивые графики.
Ваш подход без сомнения имеет право на жизнь, но по моему описанное выше больше соответствует UNIX-way, т.к. легче масштабируется до десятков-сотен серверов и очень легко умеет в автоматизацию. Накрутить дополнительной логике в Ansible дело нескольких минут, на крайний случай часов, и вот у вас уже есть например авто дискавери бэкендов или автоматическое указание веса бэкенда в зависимости от количества процессорных ядер на нем и все остальное, что вы только сможете придумать. ;)
Да, я это знаю. Как раз про это была эта часть моего вопроса:
Многие просто выкладывают исходники в открытый доступ, но не будучи вашим клиентом я не могу требовать их у вас.
И QEMU и ядро Linux, частью которого является KVM, публикуются под GPLv2, соответственно исходники должны быть;).
Вообще по характеристикам ноут почти копия Вашего Asus, если он у вас уже есть вы не выиграете в производительности от замены его на делл.
Использую ядро 4.16.9, дистрибутив Arch, дрова «xf86-video-intel 1:2.99.917+831+ge7bfc906-1». Проблем из-за 4К пока не видел, но не исключаю, что это из-за свежих версий софта, который я использую. Специально брал ноут только со встройкой Intel, что бы не парится с проприетарными дровами нвидии и не править их глюки.
Ну и конечно качество шрифтов сильно улучшилось, на FullHD 13-ке были заметны отдельные пиксели, с 4к пикселей не видно вообще.
Nginx кэширует ответы бэкенда, и при следующем запросе она отдается уже из кэша, а не с бэкенда. В readme в репе есть пример конфига Nginx, который реализует эту логику.
По поводу ресайза в несколько проходов. Не могли бы Вы рассказать как вы это делали и какой библиотекой? На первый взгляд похоже на проблему с алгоритмом ресайза, из-за которой он при большом изменении размера портил качество. Теоретически вариант, когда мы ресайзим большую в маленькую должен быть лучше, чем вариант, когда мы делаем «большая->средняя->маленькая», т.к. не происходит потери на шаге «большая->средняя».
Вместо "/test.png" в том месте страницы, где нужна маленькая версия мы пишем "/test.png@75". Все запросы с @ в конце отправляются nginx'ом на ресайз бэкенд. Он в свою очередь пасит url, скачивает оригинал ("/test.png"), ресайзит его до нужного разрешения и отдает nginx'у. Nginx кэширует результат и отдает его клиенту.
Если же это проявляется в заметных артефакт, то есть смысл смотреть на алгоритм ресайза и его настройки.
На всякий случай уточню предыдущий коммент: мы храним только оригиналы в максимальном используемом разрешении (200х200 в примере). Менее качественные версии генерируются динамически и только кешируются на некоторое время.
Второй момент: например про главную. 75х75 это размер, определяемый версткой страницы, то есть в верстке есть контейнер 75х75 пикселей и мы вставляем туда версию нужного размера. Мы естественно не вставляем 75 версию в 200 контейнер.