SATA и многоядерность?

Не думаю, за параллельным доступом - это к NVMe SSD.

что за задачи? Хотелось бы тоже посмотреть. На определенном языке или просто обобщенные?

В секунду прога обращается к SSD 30000 раз, читает с разных позиций по несколько десятков байт.

Данные каждый раз разные, или есть частые обращения к «популярным» данным? Если второе, то обеспечьте достаточный объем оперативки для кэша ФС, и все будет прекрасно.

Обычно если тебе нужно 12000 раз в секунду дёргать диск, при этом всего 500 Кб в сумме, ты что-то делаешь не так. Нужно использовать упреждающее чтение, кеширование, оптимизированные структуры данных.

кеширование

В Linux и так хороший кэш - считай, все ядро вокруг него построено. А остальное и правда не помешает.

Накопитель какой? Почему вы решили, что он вытянет 120 тыс. IOPS'ов? И как вы грузите ядра — это разные процессы или потоки в одном процессе?

по несколько десятков байт

Ну с накопителя то за обращение читается побольше байт.

Этот SSD выделен по задачу или система стоит на нём же и туда пишутся логи и т.д.? Планировщик ввода/вывода какой?

Ему хочется на порядок больше (120000 в секунду).

В секунду прога обращается к SSD 30000 раз

Вы нас обманываете.

Этот SSD выделен по задачу

Выйти на 120k IOPS очень нетривиально. ОЧЕНЬ. Господин лжёт.

Какой объём данных? Если 32 Гб - считайте весь объём в память, и работайте из памяти.

скорее всего автор мерил кэшированные запросы. Когда жабу изучал тоже ради интереса мерил насколько медленно io без буфера. Для буферизации уже в самой ранней весии специально написали классы

Да, чтобы оценить реальное количество обращений к носителю, нужно мониторить количество major page faults.

Пишу быдло-майнер, алгоритм подразумевает много данных со всего диска с разных областей. Авторы сильно намудрили, стараясь максимально усложнить добычу монетки. Чтение по 3, 5 байт, 31,33, 4090, 4100 байт и всё в таком роде. В памяти нестандартные типы по 9 бит, 500 бит и всё такое. Я так понимаю что-то там выровнять и оптимизировать не имеет смысла, потому что так задумано изначально.

Как заявляется - это будет убийца кэшей всех уровней, многоядерности, убийца видеокарт, асиков, ботнетов и всего такого. Поживём - увидим.

Как бы работает все неплохо, но занято 1 ядро. А 100 ядер = будет хешрейт X100 :)

Объем 4 ТБ, в память не загрузить. Кэш линукса тоже особо не поможет, потому что обращение каждый раз в разные области, рассчитать заранее невозможно (или не придумал как). Чтоб знать куда на следующей итерации обращаться, надо обратиться по текущим указателям, далее XORить их с предыдущими, далее XOR с «магическим числом» + nonce, короче дебри и муть.

Ставить несколько дисков по 4Тб пока не хочется :)

Вроде как IOPS упираются в возможности SATA, 32 очереди или что-то такое. Спасибо человек выше написал, что надо NVME. Как поставлю такой, отпишусь тут, помогло или нет.

попробуй добавить контроллер

Но пока нужно 4 ядра на 1 SSD.

https://www.thomas-krenn.com/en/wiki/Linux_Multi-Queue_Block_IO_Queueing_Mech...

devl547@boxy:~$ cat /sys/block/sda/queue/scheduler
none [mq-deadline]

типичный лимит по IOPs 10k всего лишь, так что 30000 - это значит не случайный, а довольно часто на один блок приходящиеся.

типичный лимит по IOPs 10k всего лишь

А то что пишут в свойствах SSD 70-80k IOPS даже для дешевых накопителей на sata, это всё врут? А у моего NVME Samsung 980 Pro так вообще обещают 1М IOPS.

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

В твоем самсунге есть SLC-кэш, и эти цифры, скорее всего, относятся к закэшированным данным.

У современных SSD есть не то что SLC, а даже RAM-кеши. Разумеется, там очень много IOPS можно выжать, особенно во втором случае. Но есть нюанс.

RAM-кеши

RAM-кеши даже у IDE HDD были