У PQ.Hosting интерфейс проще и быстрее. Всё ключевое — на одном экране, развёртывание занимает пару минут. Особенно это чувствуется, если часто переключаешься между локациями или управляешь сразу несколькими VPS.

Поддержка

REG.RU работает через тикеты, отвечает стабильно, но ощущается некоторая дистанция. Хотя возможно это мне так “повезло”, ситуация максимально “индивидуальная”. У PQ.Hosting — техподдержка, которая реально общается: через Telegram, почту, live-чат. В моём случае ответы приходили быстрее, и по делу.

REG.RU остаётся узнаваемым и массовым провайдером. Но если смотреть по цене, скорости включения, прозрачности тарифов и удобству панели — PQ.Hosting оказывается заметно выгоднее. Особенно если не принципиально размещение в РФ (хотя РФ регион имеется и у PQ.Hosting), а важнее — соотношение цена / производительность.

А как вам Reg.ru? Делитесь своим мнением в комментариях.

Бесплатный хостинг - не значит ущербный. Это вход в нормальную экосистему, не маркетинговый мусор.

А теперь то, что конкуренты продают отдельно - у нас просто включено

• A+ по Security Headers - проверено через securityheaders.com (На секундочку, НИ ОДИН хостинг во всем мире не предоставляет такую защиту сразу "из коробки". А у нас это просто есть. Для всех, даже на бесплатном тарифе).

• Поддержка всех стеков: WordPress, Node.js, Python, PHP, Laravel, Symfony, PostgreSQL, MongoDB, MariaDB и даже Perl

• Настоящая админка - DirectAdmin с кастомом. Никакого cPanel с интерфейсом 2007 года

• Встроенная почта, Cron, SSH, Web терминал, email-алиасы

• Бесплатный SSL, домен, CMS-установщик, мгновенная активация

• Прозрачный контроль над DNS, файлы, базы, FTP - всё через 1 панель

Мы не просто хостим. Мы строим своё комьюнити

Вот где мы реально выбиваемся из шаблона:

• forum.webhostmost.com - который пока что просто есть =D

• docs.webhostmost.com - не “чекни FAQ”, а пошаговые инструкции, гайды, примеры

• blog.webhostmost.com - статьи, сравнения, боль и правда про хостинг

• Telegram-чат - где отвечают не “менеджеры по клиентскому счастью”, а девопсы, саппорты, дизайнер и даже директор

И да, индустрия нас пока что ненавидит. Потому что:

• Мы не делаем апсейл на функции, которые должны быть базой

• Мы не ограничиваем пользователей, как shared-хостинги образца 2014

• Мы не прячемся за чат-ботами, а реально сидим в комментах

Кстати, вот вам немного сравнений с GTMetrix и SecurityHeaders рандомного UK сайта, который хостится на любом другом хостинге (в этом примере на SiteGround) и на нашем:

SiteGround:

WebHostMost:

И да, нас можно пнуть, задать неудобный вопрос и даже “о ужас” - поспорить с нами.
Но мы ответим. Мы рядом. Мы - WHM Crew.

— Мы? Мы WHM Crew (Для вас в первую очередь “Новореги” =D).
— А что происходит? Это блог о нашем продукте, аналогов которому по качеству - просто нет (webhostmost.ru, кста).

Тут мы будем рассказывать, как мы решили обойти всех стариков индустрии: тех, кто просыпается только когда цены на автопродление надо повысить.

У нас всё иначе. Скорость загрузки сайта - не секунда, а полсекунды.

Цена - Стабильнее любой мировой валюты, не меняется НИКОГДА.

Техподдержка - не чат-бот с философским настроем (Но это пока что, эту тему мы раскроем в одном из постов и вы… Ахуеете? =D), а реальные люди. Да, даже по ночам.

И всё это - не корпорация. Мы - команда, почти семья, нас объединяет единая цель: СДЕЛАТЬ САМЫЙ УНИКАЛЬНЫЙ И ДОСТУПНЫЙ ПРОДУКТ НА РЫНКЕ ВЕБ ХОСТИНГА. Мы друг друга знаем в лицо, а не по ID в трекере задач. И скоро вы узнаете нас тоже.

Мы будем честно сравнивать свой продукт другим. Показывать, где "корпорации" косячат (А они все пиздец, как косячат =D), а где мы уже сделали лучше.

Будем кидать мемы, примеры, графики, истории, а иногда и просто душу.

Как вы уже наверняка заметили, у нас нет “Корпоративной этики”, мы привыкли говорить и делать “как чувствуем”, идя не просто в “ногу со временем”, а переворачивая всю веб хостинг индустрию.

Прекрасно понимаем, что для вас это пока что пустые слова, но наши последующие посты будут прямым доказательством того, что это не просто слова и АНАЛОГОВ НЕТ, как зумеры заставляют менять свой подход работодателей, так мы и наш продукт - заставляет крупные корпорации встать с банки (как в том видосе, да), набитой деньгами и обратить внимание на свое комьюнити.

И если вы сидели на хостинге, где сайт грузится с молитвой и жертвоприношением - добро пожаловать домой и до встречи в следующих постах!)

Важность в системах Linux

В Linux параметр максимального размера I/O существенно влияет на эффективность чтения и записи данных с устройств хранения. Он оказывает влияние на следующие аспекты производительности:

1. Баланс между пропускной способностью и задержками:

• Пропускная способность (Throughput): Крупные размеры I/O-запросов увеличивают общую пропускную способность ввода-вывода за счёт обработки больших блоков данных за одну операцию. Это снижает накладные расходы на обработку множества мелких запросов, особенно эффективно при работе с последовательными потоками данных (видеостриминг, резервные копии баз данных).

• Задержки (Latency): В то время как большие размеры I/O-запросов могут повысить пропускную способность для больших наборов наборов, они также могут увеличить задержку отдельных операций. Это происходит потому, что более крупные запросы требуют больше времени для завершения. Поэтому необходим баланс между улучшением производительности и допустимым уровнем задержек, особенно в чувствительных к задержкам интерактивных или real-time приложениях. В таких случаях предпочтительнее меньшие размеры запросов.

2. Использование CPU:

• Увеличение размера запросов уменьшает нагрузку на CPU, поскольку снижается число переключений контекста и прерываний, связанных с обработкой отдельных запросов ввода-вывода.

3. Использование памяти:

• Максимальный размер I/O влияет на объём выделяемой памяти под буферы ввода-вывода, что также отражается на общем использовании памяти системой.

Факторы, влияющие на максимальный размер I/O

Есть несколько факторов, которые влияют на максимальный размер запросов в Linux:

• Аппаратные ограничения: Значение max_sectors_kb не должно превышать аппаратные возможности накопителя (значение параметра max_hw_sectors_kb). Превышение аппаратного лимита может привести к ошибкам или снижению производительности.

• Драйверы устройств: Драйверы контроллеров хранения и накопителей могут задавать свои лимиты на размер запросов.

• Ограничения файловых систем: У разных файловых систем разные лимиты на размер запроса ввода-вывода.

• Параметры ядра Linux: Настройки блочных устройств ядра влияют на размер запроса.

Бенчмаркинг и мониторинг

Для определения оптимального размера I/O-запросов необходимо проводить тестирование (бенчмарки) и мониторить показатели производительности (например, с помощью утилиты iostat).

Рекомендуется учитывать:

• Red Hat советует, чтобы значение max_sectors_kb было кратно оптимальному размеру I/O и внутреннему размеру блока стирания устройства. Если таких данных нет, рекомендуется выставить значение, совпадающее с логическим размером блока устройства.

• Характеристики рабочей нагрузки: разные приложения выигрывают от разных размеров I/O.

• Особенности накопителя: HDD и SSD имеют разные оптимальные диапазоны размеров I/O.

• Ресурсы системы: доступная память и мощность CPU влияют на выбор оптимального размера I/O.

Практические аспекты настройки

Для настройки max_sectors_kb используется команда:

/sys/block/{device}/queue/max_sectors_kb

Например:

echo 256 | sudo tee /sys/block/sda/queue/max_sectors_kb

Данная команда устанавливает максимальный размер запроса в 256 КБ для диска /dev/sda. Перед изменениями желательно протестировать настройки на тестовой системе во избежание негативного влияния на производительность или стабильность системы.

Изменения параметра действуют только до перезагрузки системы. Чтобы изменения сохранялись, добавьте команду в rc.local или настройте сервис для применения параметров при загрузке.

Практическое исследование

Рассмотрим практический сценарий. Создадим лабораторную среду на Linux-сервере и проверим производительность диска. Нагрузку (IOPS) будем генерировать с помощью инструмента fio, а мониторинг производительности проводить с помощью утилиты iostat. Наша задача — оценить влияние параметра max_sectors_kb на производительность системы.

Среда для тестирования:

• Тип EC2-инстанса: c5.12xlarge

• EBS-том:

• тип: GP3

• размер: 20 GiB

• IOPS: 3000

• пропускная способность: 750 MB/s

• Операционная система: Amazon Linux 2

Проверка дисков и установка fio

Для начала проверим доступные диски:

Мы будем создавать нагрузку на диск nvme1n1 при помощи утилиты fio и параллельно мониторить производительность диска, в частности показатель IOPS. Если fio не установлен, используйте команды ниже:

Для Amazon Linux:

sudo yum install -y fio

Для Ubuntu:

sudo apt-get install -y fio

Запуск теста

Откройте два терминала одновременно:

Терминал 1: Генерируем нагрузку:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=256K --ioengine=libaio --direct=1 --name=volume-initialize

Терминал 2: Мониторим диск:

iostat 1 -d /dev/nvme1n1

Обратите внимание, что в команде fio мы задали размер запроса 256 KiB.

Наблюдения

На первом скриншоте видно, что утилита fio генерирует 1082 IOPS, однако утилита iostat показывает примерно 2164 IOPS (то есть в два раза больше).

Причина различий

Чтобы выяснить причину этого несоответствия, проверим значение параметра max_sectors_kb:

cat /sys/block/nvme1n1/queue/max_sectors_kb

Объяснение:

Инструмент fio создавал IOPS с размером 256 KiB, а max_sectors_kb был установлен на значение 128 KiB. В результате ядро Linux разбивало каждый запрос на два меньших запроса по 128 KiB каждый (256 KiB = 128 KiB × 2). Именно поэтому количество операций, регистрируемых iostat, было в два раза больше, чем указывал fio (1082 × 2 = 2164).

Важно: Увеличение числа запросов из-за неправильно настроенного max_sectors_kb может негативно повлиять на производительность сервера и привести к троттлингу производительности диска (например, EBS-тома), если число операций превышает базовый уровень IOPS.

Проверка максимального аппаратного лимита max_hw_sectors_kb

Проверим максимальное значение I/O, которое поддерживает наш сервер:

cat /sys/block/nvme1n1/queue/max_hw_sectors_kb

Результат: наш сервер поддерживает максимальный размер I/O-запроса в 256 KiB.

Попытка увеличения max_sectors_kb

Попробуем увеличить значение до 512 KiB:

echo 512 | sudo tee /sys/block/nvme1n1/queue/max_sectors_kb

Результат: Мы получили ошибку «Invalid argument» («Недопустимый аргумент»), так как указали значение, превышающее аппаратный лимит max_hw_sectors_kb.

Теперь установим допустимое значение 256 KiB:

echo 256 | sudo tee /sys/block/nvme1n1/queue/max_sectors_kb

Результат: Значение успешно изменено на 256 KiB.

Повторный запуск теста fio

Повторим тест командой:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=256K --ioengine=libaio --direct=1 --name=volume-initialize

Результат: После изменения параметра max_sectors_kb количество операций IOPS, отображаемое fio и iostat, совпало.

Заключение:

Максимальный размер I/O-запроса (max_sectors_kb) является мощным инструментом для тонкой настройки производительности дисковой подсистемы в Linux. Правильно подобранное значение позволяет оптимизировать производительность ввода-вывода и снизить нагрузку на CPU, однако следует учитывать возможное увеличение задержек и аппаратные ограничения. Любые изменения параметров производительности следует предварительно тестировать и внимательно анализировать перед внедрением в продуктивную среду. Это гарантирует стабильность работы системы и её оптимальную производительность в различных сценариях.