Копилка Герасима
Ну, либо просто ограничить-таки ему [SQL-серверу] память.
Всё это хорошо и правильно, однако, вопрос с оперативной памятью у Герасима уже решён.
Думаю, 64 Гигабайт ему хватит на ближайшие 5-10 лет. А если через 5-10 лет памяти будет не хватать, можно добавить ещё 64 Гигабайта (до 128). А помониторить запись на диск в течение месяца можно программой HDTunePro. Запустить её на сервере 1-го числа и остановить 31-го. Всё будет показано. Вопрос в том, что сегодня средний размер результата 200 байт, а завтра - 2 Килобайта.
2 Килобайта - не Бог весть какой размер, а жизнь SSD диску сократит в 10 раз! По моим прикидкам, SSD TBWrite для SQL-сервера, должен быть не менее 2400 ТВ. И ещё: все производители SSD дисков молчат как партизаны на допросе: "Сколько лет их SSD хранит данные при отключённом питании?". Вот у меня Барракуда 80ГБ лежит уже 10 лет на полочке(с моими фото, музыкой итд..). Намедни проверил. Все данные целёхонькие. А через сколько лет разрядятся конденсаторы SSD диска?
p.s: Посмотрел на системный диск Герасима(SSD 512 ГБ). Отъедено очередные 0,1 Терабайта. Душераздирающее зрелище. 
В Windows есть очень удобная команда, которая с командной строки которая показывает, сколько в данный момент сброшено в файл подкачки и какой был максимум сброса в файл подкачки с момента загрузки Windows:
wmic pagefile
Можно будет посмотреть, сколько через 2 - 3 дня там будет сброшено в файл подкачки.
Сейчас, в первый день работы, я полагаю там ещё пока нули.
Можно будет посмотреть, сколько через 2 - 3 дня там будет сброшено в файл подкачки.
Юра, я Вам и так скажу:"Нисколько". Вопрос с памятью решён капитально. Красота!
Ещё раз, СПАСИБО всем, кто поучаствовал в решении проблемы.
О том, сколько нужно на самом деле 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.
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-ы). И получающийся объём записываемых данных - снова не велик.
И получающийся объём записываемых данных - снова не велик.
Классные рассуждения.. Куда Вы смотрите, я так и не понял.
А теперь смотрим: приложение ODLS BS
Last 100 results Avg. size: 1,483 KBytes - То есть, ~ 1,5 Мегабайт.
Осталось только дождаться десяток-другой СридРиперов , и они порвут купленный нами SSD как Тузик грелку.
Можно поcмотреть и какую-нибудь ВУшку. Например, https://gerasim.boinc.ru/users/viewWorkunit.aspx?workunitid=51953025
Results: Size (bytes): 1,520,880
=====
p.s. По-моему, с SSD диском для баз данных всё ясно - не подходит. Маловат ресурс перезаписи.
На счету Герасима 4810 рублей. Карта Сбербанк "Мир": 2202 2003 2821 3697
Выбераем 4 недорогих HDD по 1 TB и ставим их в RAID-0.
Справедливости ради, WU'шек с результатом в 1,5 МБ мало: эта порция ~20 тыс. и за ними еще одна будет примерно такая же. Остальные большинство маленькие, меньше 1 КБ
Цитата: SerVal от 25.10.2021, 09:10И получающийся объём записываемых данных - снова не велик.
Классные рассуждения.. Куда Вы смотрите, я так и не понял. ?
На указанные вами же размеры в 200 байт и 2 кбайта. Если же средний размер файлов будет на самом деле на уровне мегабайт, то, как уже говорил, каталог с файлами результатов надо вынести с SSD-тома на HDD (лучше, конечно, на зеркало). Средняя скорость записи на HDD - десятки мбайт/с, такой темп получения результатов, вроде бы пока не присутствует. На миллион WU размером в 1 Мбайт вполне хватит двух дисков в по 1 TB в RAID 1, особенно, если их оттуда будут забирать хотя бы раз в неделю.
P.S. Если посмотрите на расчёт, то там на последнем шаге я до этого вместо лет написал месяцев. А должно быть именно "100 лет". Сейчас поправил. Если к обозначенным ~100 .. 200 Гб в месяц добавится миллион файлов по 1 Мбайту в тот же месяц, то это будет 1.2 Тб в месяц. Даже самого дешёвого SSD на 150 Tb хватит где-то лет на 10. Так что можно просто взять SSD и наблюдать, а там уже видно будет. Тем более, что у современных HDD, на самом деле ресурс по записи тоже есть. 
И, да, повторю, нужны HDD для нормального бэкапа.
Альфовские 5000 так и не всплыли?