Форум

Уважаемые посетители. В связи с массовой регистрацией на форуме спамовых и рекламных аккаунтов нам пришлось установить некоторые защитные программные блоки. Если при регистрации на Ваш почтовый адрес не придет письмо с паролем для активации учетной записи, прошу написать на адрес tpp12@rambler.ru или boinc.ru@yandex.ru. Я активирую учетку в ручную и вышлю Вам временный пароль.
Пожалуйста or Регистрация для создания сообщений и тем.

Копилка Герасима

Ну, либо просто ограничить-таки ему [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 Терабайта. Душераздирающее зрелище. 🙁

Array

 

В Windows есть очень удобная команда, которая с командной строки которая показывает, сколько в данный момент сброшено в файл подкачки и какой был максимум сброса в файл подкачки с момента загрузки Windows:

wmic pagefile

Можно будет посмотреть, сколько через 2 - 3 дня там будет сброшено в файл подкачки.

Сейчас, в первый день работы, я полагаю там ещё пока нули.

 

 

Array

Можно будет посмотреть, сколько через 2 - 3 дня там будет сброшено в файл подкачки.

Юра, я Вам и так скажу:"Нисколько". Вопрос с памятью решён капитально. Красота!

Ещё раз, СПАСИБО всем, кто поучаствовал в решении проблемы.

Array
Yura12 отреагировал на эту запись.
Yura12

О том, сколько нужно на самом деле 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, которые должны выгружаться раз в сутки.

Array

P.P.P.S. Когда результат засчитывается, то обновляются также и таблицы team, user, host и host_app_version.

Но: 1) Эти изменения делаются только когда результат засчитывается, а не при изменении любого состояния на любое (т.е. уже в 5 раз реже); 2) Все эти таблицы очень небольшие (team - там считанное число блоков!), должны сидеть в кэше, в каждой странице - по значительно большему набору записей и, между записью обновлённых страниц из кэша на диск, они должны обновляться по несколько раз (тут уже важно правильно настроить checkpoint-ы). И получающийся объём записываемых данных - снова не велик.

Array

И получающийся объём записываемых данных - снова не велик.

Классные рассуждения.. Куда Вы смотрите, я так и не понял. 🙂

А теперь смотрим: приложение 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.

Array

Справедливости ради, WU'шек с результатом в 1,5 МБ мало: эта порция ~20 тыс. и за ними еще одна будет примерно такая же. Остальные большинство маленькие, меньше 1 КБ

Array
Цитата: 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 для нормального бэкапа.

Array

Альфовские 5000 так и не всплыли?

Array
Цитата: DrMOS от 25.10.2021, 16:26

Альфовские 5000 так и не всплыли?

Пока нет. 🙁  Завтра, часов в 11 ещё схожу в Сбербанк.

 

Array