- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Доброго времени суток. При заказе выделенного сервера(под vps), мы решили протестировать его, и заметили очень странную ситуацию, а именно скорость работы дисков. К слову, мы всегда использовали solusvm для управления серверами.
Конфигурация сервера: 2 x Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz, 322GB - ОЗУ, Установлен контроллер - MegaRAID SAS 9361-8i. К нему подключены - 8 дисков в 50 рейде, по 980гб(SAMSUNG MZ7LM960HCHP-00003). Результаты скорости работы:
На мастер ноде, мы получили показатели:
write: 1.1GB/s
read: 3.1 GB/s
На vps сервере, мы получили показатели:
write: 413 MB/s
read: 667 MB/s
Нас не очень обрадовал результат чтения на мастер сервере, при 50 рейде и рейд контроллере. К слову, режим работы рейд контроллера:
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Мы решили протестировать также kvm виртуализацию на Proxmox. У него мы получили такие показатели:
На мастер ноде:
write: 1.2 GB/s
read: 2.3 GB/s
на vps сервере:
write: 270 MB/s
read: 2.3 GB/s
Тут мы задумались, как может быть так, чтобы на одной виртуалицаии c идентичными конфигурациями, скорость дисков отличается. Мы решили переустановить сервер снова на solusvm, только установить raid10, а не 50.
Результаты на мастер ноде:
write: 700MB/s
read: 1.9 GB/s
Результаты на vps:
write: 400 MB/s
read: 700 MB/s
Результаты не сильно отличались от первого тестирования. Ну и мы для примера решили протестировать vmware на 50 рейде, и вот мы и удивились его результатом:
На VPS сервере:
write: 140 MB/s
read: 3.0 GB/s
Отсюда у нас возникает вопрос, какой показатели или настройка, может влиять на скорость чтения? Если сравнить proxmox KVM с solusvm KVM, то мы видим, что чтение на proxmox лучше чем на solusvm, хотя они используют одну виртуализацию kvm. Их отличие только в том,solusvm использует lvm, а proxmox .qcow.
Виртуализацию vmware, мы протестировали для того, чтобы убедится что проблема заключается именно в kvm.
А какой способ виртуализации дискового контроллера используется? Надеюсь, virtio-scsi или virtio? Хранилище на основе чего?
А какой способ виртуализации дискового контроллера используется? Надеюсь, virtio-scsi или virtio? Хранилище на основе чего?
Используется virtio.
Хранилище на основе ссд дисков и рейд контроллера.
Тестировать мегабайты в секунду на 3D TLC дисках - пустое занятие. Там в один день прилетит 3 Гб/с а в другой день - 1 Мегабайт в секунду. У вас может быть что угодно - процесс сбора мусора, заполненность дисков данными, работа контроллера и т.д. Это для гипервизора.
На виртуалке я бы посмотрел на размер сектора при условии, что драйвер virtio.
Но вообще лучше отталкиваться от iops-ов
И ещё одно - у вас на Proxmox скорее всего используется ZFS, которая активно кэширует все данные в память. Чтобы проводить тесты надо либо использовать Ext4 либо указывать размер тестового файла в 5-6 раз больше объема ОЗУ и заполнять его рандомными данными (не нулями).
Тестировать мегабайты в секунду на 3D TLC дисках - пустое занятие. Там в один день прилетит 3 Гб/с а в другой день - 1 Мегабайт в секунду. У вас может быть что угодно - процесс сбора мусора, заполненность дисков данными, работа контроллера и т.д. Это для гипервизора.
На виртуалке я бы посмотрел на размер сектора при условии, что драйвер virtio.
Но вообще лучше отталкиваться от iops-ов
И ещё одно - у вас на Proxmox скорее всего используется ZFS, которая активно кэширует все данные в память. Чтобы проводить тесты надо либо использовать Ext4 либо указывать размер тестового файла в 5-6 раз больше объема ОЗУ и заполнять его рандомными данными (не нулями).
Скорость показывает постоянно одинаковую. И судя по тому, что при смене рейд ничего не меняется, то дело явно в типе виртуализации и метода хранения данных. Может в LVM есть какие-то ограничения, чтобы 1 VPS не накрыла всю ноду?
Скорость показывает постоянно одинаковую. И судя по тому, что при смене рейд ничего не меняется, то дело явно в типе виртуализации и метода хранения данных. Может в LVM есть какие-то ограничения, чтобы 1 VPS не накрыла всю ноду?
Причём здесь LVM?
Ограничения обычно ставятся на IOPS-ы, а не на пропускную способность. Плюс сам драйвер имеет свой потолок, но он как правило сильно выше 1 Гб/с.
У вас везде Thick provision eargy zeroed? Везде VM-Tools установлены?
Какую скорость вы хотите поднять - чтение или запись?
Я спрашиваю вас потому, что у вас слишком большие различия в скорости между гипервизором и виртуалкой, там должно быть процентов 10.
У вас везде Thick provision eargy zeroed? Везде VM-Tools установлены?
Какую скорость вы хотите поднять - чтение или запись?
Нас Vmware вообще не интересует. Мы чисто решили для сравнения протестировать. Мы хотим, чтобы KVM работал нормально, а не резал скорость хотя бы чтения.
С iOPS у нас все в порядке. Именно обычная команда dd на чтение сильно проседает на VPS и мы не можем понять причину.
dd на запись:
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync oflag=direct
dd на чтение:
dd if=test of=/dev/null bs=1M count=1024 iflag=direct
Нас Vmware вообще не интересует. Мы чисто решили для сравнения протестировать. Мы хотим, чтобы KVM работал нормально, а не резал скорость хотя бы чтения.
С iOPS у нас все в порядке. Именно обычная команда dd на чтение сильно проседает на VPS и мы не можем понять причину.
dd на запись:
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync oflag=direct
dd на чтение:
dd if=test of=/dev/null bs=1M count=1024 iflag=direct
У вас на Proxmox стоит ZFS?
У вас на Proxmox стоит ZFS?
Честно говоря, не помню, выбирал ли zfs. Разве это может повлиять на конечную скорость на самой VPS?
Попробуйте протестировать raw образы.
Они должны быть более производительны.
Честно говоря, не помню, выбирал ли zfs. Разве это может повлиять на конечную скорость на самой VPS?
Да может, потому что там вопрос в кэшировании на чтение и синхронизации на запись.
Попробуйте в настройках ZFS отключить синхронизацию записи, вроде бы fsync=off, и протестируйте снова на гипервизоре и в виртуалке, но не нулевыми файлами, а реальными.
И как бы дальше поставьте цель - чего вам хочется?
Может ли гипервизор резать скорость виртуалки? Да может, 5-10%. Или больше, если сами полезете настраивать.
"Почему у меня всё так медленно"? Вот тут надо понимать, на какой ОС вы остановились, какую ФС выбрали, и если это ZFS, то смотреть настройки тома, в котором лежат диски виртуалок, с какими параметрами он подключен.
С ходу скажу - в месте, где лежат виртуалки, не должно быть ни компрессии Zlib, ни дедупликации, ни синхронизации записи (хотя она конечно полезна для надежности, но скорость рубит сильно).
Пишите.