157 ответов в этой теме

[VVS]

Но доля правды в его словах есть. Было бы хорошо если бы Доктор не проверял одни и те же файлы по несколько раз. Создать что-то вроде списка уже проверенных файлов. Полагаю и время проверки значительно сократилось бы и возможно нагрузка.

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

[VVS]

Я кажется немного не правильно высказался. Извиняюсь. Я имел ввиду, создать список заведомо безопасных файлов.

И таскать с собой базу немерянного размера и для каждого файла вычислять MD5 и сравнивать с этой базой?
Или проверять по подписи?
А если подпись отозвана (вспомните Realtek)?
Слишком много "если", особенно с учётом того, что быстрая проверка в сканере проверяет все опасные места, поэтому полная IMHO не нужна от слова совсем.

[FanIT]

И таскать с собой базу немерянного размера и для каждого файла вычислять MD5 и сравнивать с этой базой?

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

[usverg]

что вычислить хэш файла порой бывает быстрее

почти всегда.

[IlyaS]

Вот когда сканирование реально может помешать – так это когда оно происходит действительно слишком быстро и съедает весь I/O, в котором есть потребность у других процессов. Приоритеты по I/O вроде бы не устанавливаются.

Да, на некоторых компах при такой утилизации диска становится просто невозможно работать во время даже быстрого скана. Оно не просто лагает, все встает напрочь. А файлы, как-будто, сначала сканятся аркадием, а затем те же файлы движком. Получается очень тормозной I/O.

[VVS]

Т.е. тогда, когда проц настолько быстрый, что может проглотить больше, чем ему винт может отдать?
Прикольно, никогда с таким не сталкивался.

[IlyaS]

та нет, просто x64 10ка с i3-4130, 4ГБ ОЗУ и медленным зеленым винтом от WD. Проц да, наполовину отдыхает, а диск на максимуме по манагеру, хотя скорость чтения очень низкая - 0.1-2МБ/с и уже 100%. Может процесс лассо приоритет IO рабочим процессам задать?

Сообщение было изменено IlyaS: 29 Ноябрь 2018 - 15:18

[IlyaS]

P.S. Комп и так диском тормозит, со сканом совсем жестко. Без АВ было неплохо.

[basid]

Я бы начал с ограничения числа потоков проверки до одного-двух.

HDD вообще противопоказан многопоточный доступ, а "зелёным" дискам он противопоказан особенно.

[IlyaS]

Эа фича, как написал Костя, в ЕС 11.5 еще только появится. Вот только какое кол-во движков будет умолчальным.

[SergSG]

Эа фича, как написал Костя, в ЕС 11.5 еще только появится. Вот только какое кол-во движков будет умолчальным.

Я бы по дефолту оставил один. Может желание проверять поубавится.

[IlyaS]

SergSG, согласен! Если б можно было еще снижать приоритет I/O потока сканирования.

[usverg]

IlyaS, неплохо бы, конечно, но что-то подсказывает, что в такой ситуации (при отсутствии ionice для M$) график нагрузки на HDD приобретёт шибко ступенчатый характер, а хорошо ли это - большой вопрос.

[SergSG]

SergSG, согласен! Если б можно было еще снижать приоритет I/O потока сканирования.

Зачем? Можно просто снизить приоритет процесса, тогда он и доступ к диску будет получать последним, если нет других желающих. Но если уж начал читать, должен вычитать максимально быстро.

 

Только зачем все это надо? Для желающих посканировать достаточно двух режимов - скоростное и фоновое. Пусть развлекаются кому как нравится.

Когда то я эксперимента ради понизил приоритеты докторских процессов до минимума. Так я при этом смог еще и нормально видео кодировать - ничего не мешало. Причем, это был Прескот, ХР и SS 8.0.

[Afalin]

Зачем? Можно просто снизить приоритет процесса, тогда он и доступ к диску будет получать последним, если нет других желающих. Но если уж начал читать, должен вычитать максимально быстро.

Если есть какой-то процесс, которому нужно много I/O и мало вычислительных мощностей, то сканирование будет ему мешать.

[Konstantin Yudin]

Приоритеты по I/O вроде бы не устанавливаются.

выставляются. понятие приоритета это комплексная штука, там и поток и память и io

[Konstantin Yudin]

И таскать с собой базу немерянного размера и для каждого файла вычислять MD5 и сравнивать с этой базой?

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

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

[Konstantin Yudin]

Т.е. тогда, когда проц настолько быстрый, что может проглотить больше, чем ему винт может отдать?
Прикольно, никогда с таким не сталкивался.

все гораздо сложней и комплексней. I/O просто убивает все, т.к. сканируем мы медленней а в силу 32 битности крайне ограничены в ресурсах. т.е. проблема в том что при стороннем скане мы забираем движки у критичных модулей типа спайдера и гейта и чем комфортней и медленней будет сканер чем больше он будет занимать важный движок. в текущей архитектура мы на пределе. поэтому любое сканирование это зло для всей системы.

[Konstantin Yudin]

Эа фича, как написал Костя, в ЕС 11.5 еще только появится. Вот только какое кол-во движков будет умолчальным.

задавать кол-во можете любое от 0 и выше. больше чем можно максимально всеравно не получится, SE ограничивает сам если выше планки, на сегодня SE не может больше 32 для всей системы, сканерам еще меньше т.к. должна работать реал тайм часть ав.

SergSG, согласен! Если б можно было еще снижать приоритет I/O потока сканирования.

I/O приоритет выставляется не на поток а на сам хендл файла с которым идет работа.

[IlyaS]

Эа фича, как написал Костя, в ЕС 11.5 еще только появится. Вот только какое кол-во движков будет умолчальным.

задавать кол-во можете любое от 0 и выше. больше чем можно максимально всеравно не получится, SE ограничивает сам если выше планки, на сегодня SE не может больше 32 для всей системы, сканерам еще меньше т.к. должна работать реал тайм часть ав.

SergSG, согласен! Если б можно было еще снижать приоритет I/O потока сканирования.

I/O приоритет выставляется не на поток а на сам хендл файла с которым идет работа.

Тут важно именно умолчальное значение кол-ва движков,. Если будет 0 и 0 - это автоопределение как сейчас, то это не изменит уже имеющиеся задания сканирования.

Только на хэндл? Как же работает прокесс лассо, где приоритет I/O можно назначить процессу?