Это выдача atopsar на Debian ноде :)
atopsar -R 10000 -p
средние данные показываются за день
Никакой FreeBSD магии.
00:00:01 cpu %usr %nice %sys %irq %softirq %steal %guest %wait %idle _cpu_-------------------------- analysis date: 2017/11/21 --------------------------00:00:01 all 171 4 24 0 7 0 166 0 427 0 29 1 3 0 1 0 28 0 39 1 27 1 3 0 1 0 26 0 43 2 24 1 3 0 1 0 24 0 47 3 22 1 4 0 1 0 22 0 50 4 15 0 3 0 1 0 14 0 67 5 17 0 3 0 1 0 16 0 63 6 17 0 3 0 1 0 16 0 63 7 18 0 3 0 1 0 17 0 6100:00:01 pswch/s devintr/s clones/s loadavg1 loadavg5 loadavg15 _load_-------------------------- analysis date: 2017/11/21 --------------------------00:00:01 119555 53171 3.45 3.18 3.00 2.96
Пожалуйста. На ноде 35 инстанцев. Сколько приносит и сколько стоит писать не буду, чтобы обидно не было.
Показатели LA говорят, что нода к черту перегружена.
Зависит от архитектуры, архитектура рулит все. Конечно Sandy Bridge сравнивать с Haswell бессмысленно, т.к. это просто одна итерация против другой.
Разница значима только когда мы смотрим первый (Nehalem) против любого другого:
https://uk.hardware.info/reviews/6215/2/intel-five-generation-ipc-test-broadwell-haswell-ivy-bridge-sandy-bridge-and-nehalem-results
Далее E3 против E5 разница не значительная. В Single thread E3 выигрывает. E5 просто позволяет впихнуть больше ядер (за счет multi-CPU и конечно большего размера самого процессора) на одну материнку.
В принципе разница между всеми ними в наборе инструкций, кэшах и оптимизации самих процессов (performance/watt) внутри ядер. Разные сочетаемости этих наборов и приводят к текущему зоопарку. А ведь еще есть E7... Такое чувство, что с уменьшением техпроцесса количество брака выходит большим, поэтому такова разница в количестве разных версий по сути одних и тех же процессоров. Качественной разницы уже давно практически нет.
В Scalable Xeon они вообще сузили опции (самые быстрых процессоров на 1х и 2х доменную материнку больше нет вообще). Многие продавцы продают системы в полной сборке онли (заказать сразу полную систему и оплатить полностью иначе без гарантии)...
Это из разряда "был поезд с одним локомотивом и двумя, на тот что с двумя навесили 16 тысяч тонн груза, тому что с одним 10 тонн груза, только вот что с двумя имеет опытную технологию распределения нагрузки и выходит что нагрузка прыгает с одного на другой, локомотивы постоянно не разгоняются, т.к. нагрузка постоянно перераспределяется"
Гуглите NUMA, QPI и всю архитектуру SMP...
Для простоты скажу так. Отключите гипертрединг, чтобы тестировать ядра онли, отключите все power ограничители и включите и в биосе и в ОС performance и сделайте CPU пиннинг для QEMU, они это умеют теперь, после этого проверьте результаты.
Вопрос встает большой, что ж Вы там предоставляете, если даже базового понимания устройства ПК нет. А что будет когда Вы упретесь в PCIe шину на другом процессоре и забъете PCI lanes к чертям (теми же NVMe)? И Ваша мега система зависнет к чертям собачьим? Тоже на гремлинов сошлетесь?
Почитайте характеристики Вашего (я полагаю) CPU:
https://ark.intel.com/products/91767/Intel-Xeon-Processor-E5-2650-v4-30M-Cache-2_20-GHz
Там тонна экономий и шаринга.
Нормальные процессоры для массовой виртуализации пока только начали выпускать - это Intel Scalable Xeon и AMD EPYC.
Разница между ними в том, что EPYC намного мощнее и быстрее, но с багами, а Xeon стабильный (по-крайней мере на данный момент, может тоже жесть), но архитектура та же (вместо QPI теперь UPI, а количество PCIe lanes просто заставляет плакать :()
Рассмотрите наше предложение в Будапеште:
3 Core 3.4GHz Intel Xeon CPU4096MB ECC DDR3 RAM160GB SSD RAID10 Disk300mbps/Unmetered Network7 day nightly backup
Эх ПХП, ПХП... По идее если в редисе лок не ставиться на всю сессию на весь период, то скрипт выполняется в бекграунде до конца и пишет в сессию кривые данные, когда пользователь от злости обновил страницу и его новый скрипт пишет уже другие данные, на основании других записей, называется race condition, для этого и используются локи/семафоры/спины/мъютексы, в случае с файлами это как раз эксклюзивный лок на файл (который на самом деле не эксклюзивный на многих ОС), в случае с редисом - это (по идее) лок на запись в БД. В БД лок должен вестись сессионно и это отличает его от ФС, т.к. в ФС нет сессий, в БД пользователь сделал рефреш страницы, старая страница закрыла соединение с БД и соответственно транзакция откатилась, однако в случае скрипта пишущего в бекграунде Redis ничем не поможет, т.к. транзакция все равно будет завершаться, неважно сделал ли пользователь рефреш или нет.
Такой принцип работы мало отличается от ZFS (также существует транзакция, лок всего лишь запись в БД) и возможно BTRFS (не знаком), так что на новых ФС это дело не нужно (если только для кластеризации).
Так оно и в Редисе должно держать лок на сессию все время. Пока сессия открыта, в нее писать по идее не должно. Иначе коррапшн будет.
Интересно, а в Redis как эта блокировка обходится? Если изменение не будет атомарным, то будут коррапт данные или что еще хуже возможна утечка данных. Разница только в том, что Redis как и memcache держат это в памяти. Такие проблемы говорят о медленной ФС и дисках под ФС, раз IO заставляет ждать так долго.
Зачем Вам для 300мбпс SSD? Вы видео писать или раздавать будете? Для раздачи Вполне хватить RAID 10 из 4 дисков по 2ТБ для раздачи 4 ТБ на скорости до 2gbps (особенно если это делать с новой ФС навроде ZFS).
