67 ответов в этой теме

[German AW]

Базы 9-ые, и не "утоптанные" Похоже это фича - версия баз как правило ниже версии самого продукта. Что мешало сделать их 10-ми? Ну это я так, придираюсь

А версии модулей теперь где смотреть?

[Dmitry_rus]

В 9 базы пережимали, с того времени ничего не менялось

ИМХО, надо было не "пережимать" (выигрыш от упаковки весьма невелик оказался), а объединять, уменьшая общее кол-во файлов. А то скоро цифры с буквами закончатся... Да и видеть в каталоге 100500 файлов - как-то не комильфо. Опять-таки, не забываем про фрагментацию, хотя ее вклад в снижение быстродействия на NTFS незначителен (клинические случаи не рассматриваем).

[RomaNNN]

В 9 базы пережимали, с того времени ничего не менялось

ИМХО, надо было не "пережимать" (выигрыш от упаковки весьма невелик оказался), а объединять, уменьшая общее кол-во файлов. А то скоро цифры с буквами закончатся... Да и видеть в каталоге 100500 файлов - как-то не комильфо. Опять-таки, не забываем про фрагментацию, хотя ее вклад в снижение быстродействия на NTFS незначителен (клинические случаи не рассматриваем).

Зачем их видеть?

 

Чем больше файлов у баз, тем меньше нужно трафика, чтобы каждый час качать обновления. Это несомненный плюс.

[Dmitry_rus]

Ну вот 9-ку перепаковывали? Перепаковывали. Всё равно всем пришлось базы заново перекачивать. Можно было все существующие на тот момент базы объединить в 1 файл (например, в тот же drwebase.vdb). Трафик бы от этого никак не изменился. А дальше - как обычно: тудейки и еженедельные базы.

[RomaNNN]

Ну вот 9-ку перепаковывали? Перепаковывали. Всё равно всем пришлось базы заново перекачивать. Можно было все существующие на тот момент базы объединить в 1 файл (например, в тот же drwebase.vdb). Трафик бы от этого никак не изменился. А дальше - как обычно: тудейки и еженедельные базы.

Для того, чтобы сделать какие-то изменения в продукте (в данном случае еще и на серверах обновлений), нужно иметь перед собой четкую цель, которая оправдает средства.

 

Если объединить все базы в один файл, то возникает проблема. Когда выходит фикс в сигнатуре, которая находится в этой большой базе (drwebase.vdb), есть 2 варианта:

 

1) Каждый раз перекачивать этот файл с сервера (~150 МБ). Это даже звучит абсурдно.

2) Каждый раз реструктуризировать (пересобирать) большой файл из мелких. Для этого нужно писать процедуру реструктуризации, процедуру при сбое (если питание вырубилось, в итоге он побился), еще кучу всего менять. Была такое у антивируса Panda с его файлом pav.sig. Обновлялся он из-за этой процедуры достаточно долго, даже если обновление на несколько КБ.

[German AW]

Когда-то, помнится, укрупняли частями, т.е. из сотни мелки сделали штук 10 крупных, в пределах 10Мб каждая. Можно было по такому пути пойти. Просто оттягивать можно долго, но все равно рано или поздно придется что-то с этим делать. Всё-таки две сотни файлов, имхо, многовато. Да и имена присваивать скоро сложно будет - комбинации закончатся

[SergSG]

Да, базы дело больное, особенно для HDD. Легкого решения не получится.

Эффект от перепаковки оказалась практически незаметен.

 

По ходу, миф про NTFS не проходит, фрагментация влияет весьма заметно.

От виндового дефрага эффект не велик. Файлики то станут цельными, но складывать все файлы в одну кучу он не умеет.

[SergM]

От виндового дефрага эффект не велик. Файлики то станут цельными, но складывать все файлы в одну кучу он не умеет.

Про дефрагментацию HDD 

Старенько, но со вкусом.

[sergeyko]

Сливать базы и оптимизировать записи в них - процесс крайне нужный, важный, но трудоемкий. 

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

Вот при выпуске новой версии движка, это надо будет сделать обязательно. 

[SergSG]

 

От виндового дефрага эффект не велик. Файлики то станут цельными, но складывать все файлы в одну кучу он не умеет.

Про дефрагментацию HDD 

Старенько, но со вкусом.

Да, все это так в обычной жизни. Но при старте системы нужно прочитать (и не только) под пол гига баз и файлов только от АВ, а скорость чтения мелких фрагментированных, рандомно валяющихся по всему разделу файлах, падает до сотни раз по сравнению с линейным чтивом.

[SergM]

SergSG, Извини, но ниасилил. 

[SergSG]

Сливать базы и оптимизировать записи в них - процесс крайне нужный, важный, но трудоемкий. 

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

Вот при выпуске новой версии движка, это надо будет сделать обязательно. 

Какой смысл привязывать слияние к версии АВ или движка?

Это просто нужно периодически делать, по мере накопления.

[SergM]

Какой смысл привязывать слияние к версии АВ или движка?
Это просто нужно периодически делать, по мере накопления.

+++++++++++++++

[SergSG]

SergSG, Извини, но ниасилил. 

А так?

-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

                      Sequential Read :     98.950 MB/s
                      Sequential Write :     97.870 MB/s
              Random Read 512KB :     33.956 MB/s
              Random Write 512KB :     43.040 MB/s
     Random Read 4KB (QD=1) :     0.422 MB/s [   103.1 IOPS]
     Random Write 4KB (QD=1) :     1.046 MB/s [   255.4 IOPS]
   Random Read 4KB (QD=32) :     0.539 MB/s [   131.5 IOPS]
   Random Write 4KB (QD=32) :     0.963 MB/s [   235.0 IOPS]

  Test : 1000 MB [C: 54.3% (21.7/40.0 GB)] (x5)

-----------------------------------------------------------------------

При работе это не заметно, а вот при старте системы...

[sergeyko]

 

Сливать базы и оптимизировать записи в них - процесс крайне нужный, важный, но трудоемкий. 

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

Вот при выпуске новой версии движка, это надо будет сделать обязательно. 

Какой смысл привязывать слияние к версии АВ или движка?

Это просто нужно периодически делать, по мере накопления.

 

Ни в коем случае. Вообще говоря, трогать базы, не трогая движок - это глупость, потому что движок и есть dll + базы, поэтому все изменения в базах в идеале должны производиться совместно с перевыпуском движка. 

 

Все то, что делалось иначе было вынуждено. Из-за багов. 

[SergM]

А так?

Цифры и слова совпадают. На практике тоже старт фрагментированной системы системы на HDD заметно дольше,чем нефрагментированной. 

Про старт в обоих вариантах с АВ надо реально присмотреться. 

Но из опыта даже дефрагментация SSD (в режиме SSD дефрагментации) увеличивает на 2-3 сек. запуск системы (появление раб. стола, запуск всех служб и сервисов).

 

 

[SergSG]

 

 

Сливать базы и оптимизировать записи в них - процесс крайне нужный, важный, но трудоемкий. 

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

Вот при выпуске новой версии движка, это надо будет сделать обязательно. 

Какой смысл привязывать слияние к версии АВ или движка?

Это просто нужно периодически делать, по мере накопления.

 

Ни в коем случае. Вообще говоря, трогать базы, не трогая движок - это глупость, потому что движок и есть dll + базы, поэтому все изменения в базах в идеале должны производиться совместно с перевыпуском движка. 

 

Все то, что делалось иначе было вынуждено. Из-за багов. 

 Непонятно. Остается только поверить. Или наоборот.  

[SergSG]

 

А так?

Цифры и слова совпадают. На практике тоже старт фрагментированной системы системы на HDD заметно дольше,чем нефрагментированной. 

Про старт в обоих вариантах с АВ надо реально присмотреться. 

SergM, не надо. Дефрагментация склеит разбитые файлы, но как она файлы раскидает - гейтс его знает. Лотерея.

Укрупнять нужно. Или вообще придумывать чего то нового.

[oav]

Да и имена присваивать скоро сложно будет - комбинации закончатся

 

еще лет на 10 хватит

 

С пережатием первоочередная цель была не место сэкономить, а значительно увеличить скорость загрузки.

А объединение конечно будет еще, но не в одну базу.

[SergSG]

С пережатием первоочередная цель была не место сэкономить, а значительно увеличить скорость загрузки.

А объединение конечно будет еще, но не в одну базу.

Проводились какие нибудь тесты ускорения загрузки после пережатия?

А то я чойта не заметил.

Цель укрупнения тоже не место сэкономить, а ускорить чтение, особенно на HDD.

Сообщение было изменено SergSG: 28 Октябрь 2014 - 23:42