О том, сколько нужно на самом деле RAM и как определять, в общем-то сказано было, без фактических данных смысла продолжать нет. Куда потратить деньги, дело, как говорится, хозяйское. 🙂
2 Килобайта - не Бог весть какой размер, а жизнь SSD диску сократит в 10 раз!
Это можно легко оценить.
Сначала про БД.
Возьмём 1 миллион WU. Им будет соответствовать 1 миллион записей в таблице workunit и 2 миллиона в таблице result, если есть кворум 2. Размер каждой записи ~ 2 кб. Итого - 3 миллиона записей по 2 кб. Во время своей жизни, result проходит несколько состояний - unsent, in progress, pending, validated и, наконец - он удаляется. Итого - 5 изменений. Для workunit-а, по идее, поменьше, но давайте считать, что тоже 5.
Далее. Как и любая приличная СУБД, MSSQL пишет данные не отдельными записями, а блоками или страницами. В MSSQL 1 страница = 8 кб, в неё поместится около 4 записей (скорее - 3, но пусть 4, возьмём вариант похуже).
Если считать что каждый раз записи меняются независимо (что вообще говоря, при создании и удалении workunit-ов и result-ов - не так, но, опять - возьмём более плохой вариант), то мы получим, что за время жизни всех 4 записей в блоке, они в худшем случае заставят перезаписать страницу, в которой они находятся, 20 раз. Ну и хорошо! Давайте считать, сколько получается:
3 миллионов записей / 4 (записи в странице) = 0.75 миллиона страниц.
0.75 миллиона страниц * 20 раз = 15 миллионов раз записи страниц
15 миллионов записей страниц * 8 кб = 120 Гбайт.
Параллельно, конечно, данные будут записываться в лог базы. Но в него будет записываться не вся страница, а только запись. Т.е. это будет 1/20 от 120 Гбайт или + 6 Гбайт. Итого: 126 Гбайт. По факту, же, т.к. генерация и удаление workunit-ов и result-ов происходит массово, то эти два процесса будут приводить к однократной, а не 20-кратной записи страницы на диск. Т.е. на самом деле не 120, а на 2/5 меньше - 72 Гбайта. Но пусть 120 и 126 в сумме.
Это, насколько я вижу, за месяц. Тогда в год будет 1512 Гб или 1.5 Тб. Сколько там ресурс самых дешёвых SSD за 4000 р (на 250 Гб)? Около 150 Tb. (Фактический, как говорят тесты, будет в разы больше). 150 Тб/1.5 Тб/год - это 100 лет. А уже через 4 года будут совсем другие диски за совсем другие цены.
Теперь вернёмся к файлам.
Файлы у нас хранятся в файловой системе. А файловая система у нас записывается кластерами (или тоже страницами, но другими). В NTFS, обычно - 4 кб. И разница между 200 байтами и 2 кбайтами будет только в том, что файл размером в 200 байт будет целиком записан прямо в заголовке в NTFS, а ради 2-х килобайтного будет осуществлена запись в таблицу файлов и в виде страницы на диск. То есть, не 1, а 2 раза по 4 кб. Посчитаем более тяжёлый вариант для того же миллиона workunit-ов:
2 записи * 4 кб * 2 миллиона результатов = 16 Гбайт.
Смотрим на упоминавшиеся 126 Гбайт и понимаем, что пока размеры результатов не выросли до мегабайт, особо печалиться не о чем. Да, есть ещё файлы XML-запросов которые сервер принимает и отправляет. Они также порядка 1 - 2 кбайт на результат. В итоге, по видимому, всё должно в самом плохом случае уложиться в 150 .. 200 Гбайт на 1 миллион workunit-ов. (Запись внутри SSD, по идее, также должна идти страницам где-то по 4 кб, кажется, поэтому этот внутренний механизм, думаю, что можно тут пропустить). Ну а если размеры файлов будут массово подрастать до мегабайта, ну, тогда складывать именно их уже на HDD. IOPS-ность SSD тут им уже не поможет.
Время надёжного хранения данных на SSD в обесточенном состоянии - порядка полугода и выше, особенно если вы не подогреваете его постоянно градусов до 60. Если есть какие-то данные, которые хотелось бы сохранить, но их можно было бы вот так вынести из системы, физически вынув диск, - то их надо просто записать на болванку Blue-Ray. 10 штук по 25 Gb стоят ~ 700 р., 25 штук по 50 Gb (двуслойные) ~ 6700 р. А SSD должен не лежать, а работать, его для этого обычно покупают. 🙂
P.S. И, да, есть у нас давно хорошая ветка про HDD и SSD.
https://boinc.ru/forum/topic/interesnoe-o-hdd-i-ssd/
P.P.S. Можно, конечно, вспомнить, что у MSSQL есть такая база как tempdb. Но... зачем OLTP-системе, коей должен быть сервер BOINC, что-то туда писать? "Обязательная отчётность", по идее, у нас только в виде XML-ов с микроскопическими user, host и team, которые должны выгружаться раз в сутки.
P.P.P.S. Когда результат засчитывается, то обновляются также и таблицы team, user, host и host_app_version.
Но: 1) Эти изменения делаются только когда результат засчитывается, а не при изменении любого состояния на любое (т.е. уже в 5 раз реже); 2) Все эти таблицы очень небольшие (team - там считанное число блоков!), должны сидеть в кэше, в каждой странице - по значительно большему набору записей и, между записью обновлённых страниц из кэша на диск, они должны обновляться по несколько раз (тут уже важно правильно настроить checkpoint-ы). И получающийся объём записываемых данных - снова не велик.
