koral5057:
Доброго дня.
Пользуюсь OFP около 20 лет, из них 11 на win7, в начале года перешёл на win10.
На 7-ке (SP1,7601,SHA2-patch) версией 9.1 (4643.690.1951), на 10ке (10.0.17763.1217 v1809 LTSC) версией 9.3 (4934.708.2079).
Ещё c Win7 я понял, что компоненты проактивной защиты работают в OF криво, я их все выключил и использовал OF исключительно как файрволл.
Особых проблем при переходе на 10ке не заметил, разве что пришлось убирать автозапуск UI-оболочки(и сервиса) в фоновом режиме.
Все эти годы я смирился с тем фактом, что тяжёлые файловые операции, связанные с обработкой тысяч файлов в одном каталоге
заметно медленнее с Outpost, не важно, в каком он состоянии - выгружен, выключен или включен.
Имеются идентичные компьютеры как для win7, так и для win10 - есть с чем сравнивать.
Что же происходит?
Есть набор скриптов, и самописных утилит для массовой обработки текстов (txt/html).
Один и тот же набор данных обрабатывается за разное время на идентичных OC/Мат.платах, с Outpost это происходит медленней.
Неприятность даже не в этом, с ней ещё можно мириться, но иногда утилиты подвисают(фризятся) на некоторое время,
иногда на очень долгое время порядка 2-3 минут при норме выполнения несколько секунд, так, что в момент зависания даже процесс невозможно удалить.
Частота фризов зависит от общей загрузки жёсткого диска. Если параллельно запускать
несколько скриптов на одном диске, то вероятность повышается. Если фриз случается, и ему не мешать,
то через какое то время всё продолжается, но результат работы утилиты получается неверным.
Так, например, поиск вхождений текста по семплам возвращает 0 при случае точного нахождения сэмпла в тексте, т.е.,
другими словами, происходит не просто задержка, а порча данных.
Так как утилиты мои же, то однажды я скомпилировал билды с отладочной инфой, с целью выяснить, на каком этапе происходят фризы.
Оказалось, что фризятся исключительно секции кода (delphi):
Код:
Зависает внутри FindClose (это стандартная функция, если что), после завершения обхода текущей папки/каталога.
Утилит много, и в каждой есть такая секция. Но в тех утилитах, в которых, по логике своей работы, до закрытия папки
через FindClose нет открытых на запись файлов - фризов нет, я проверял на сотнях одновременных скриптов.
А вот если до цикла есть открытый на запись файл - то даже при трёх скриптах уже можно поймать фриз на 1й-2й минуте работы.
В общем, выяснив это, и причину (Outpost) я смирился, решив проблему костылём (описывать не буду), который существенно снизил общее быстродействие.
Надо заметить, что утилиты были написаны ещё в бытность XP, и там совместно с outpost (3.0.543.431) всё работало как и должно по ТЗ.
Вопрос в другом.
Прочитал без малого все 100 страниц последней ветки, и понял, чего не хватало все эти годы:
отключить проактивку насовсем, т.е. вырезать. Как я теперь понимаю, это возможно.
Что сделано:
- Отключены хуки wl_hook.dll+wl_hook64.dll в реестре "AppInit_DLLs" по обеим веткам x64/WOW64,
- Отключена spae.dll через переименование (у меня тоже файл логов spae.log растёт очень быстро на обеих машинах с win7/win10)
- Отключены плагины .ofp через переименование файлов в папке plugins_acs:
downloader.ofp, improve_net.ofp, hips.ofp, sand.ofp,
- Отключен драйвер Sandbox64.sys через реестр HKLM\SYSTEM\CurrentControlSet\Services\SandBox
параметр "Start"=dword:00000004 (сервис/служба выключен)
- в файл machine.ini внесены изменения:
Поправьте, покритикуйте, если кто в теме, всё ли сделано для того, чтобы выпилить
проактивную защиту на корню, если это вообще возможно?
Доброго дня.
Пользуюсь OFP около 20 лет, из них 11 на win7, в начале года перешёл на win10.
На 7-ке (SP1,7601,SHA2-patch) версией 9.1 (4643.690.1951), на 10ке (10.0.17763.1217 v1809 LTSC) версией 9.3 (4934.708.2079).
Ещё c Win7 я понял, что компоненты проактивной защиты работают в OF криво, я их все выключил и использовал OF исключительно как файрволл.
Особых проблем при переходе на 10ке не заметил, разве что пришлось убирать автозапуск UI-оболочки(и сервиса) в фоновом режиме.
Все эти годы я смирился с тем фактом, что тяжёлые файловые операции, связанные с обработкой тысяч файлов в одном каталоге
заметно медленнее с Outpost, не важно, в каком он состоянии - выгружен, выключен или включен.
Имеются идентичные компьютеры как для win7, так и для win10 - есть с чем сравнивать.
Что же происходит?
Есть набор скриптов, и самописных утилит для массовой обработки текстов (txt/html).
Один и тот же набор данных обрабатывается за разное время на идентичных OC/Мат.платах, с Outpost это происходит медленней.
Неприятность даже не в этом, с ней ещё можно мириться, но иногда утилиты подвисают(фризятся) на некоторое время,
иногда на очень долгое время порядка 2-3 минут при норме выполнения несколько секунд, так, что в момент зависания даже процесс невозможно удалить.
Частота фризов зависит от общей загрузки жёсткого диска. Если параллельно запускать
несколько скриптов на одном диске, то вероятность повышается. Если фриз случается, и ему не мешать,
то через какое то время всё продолжается, но результат работы утилиты получается неверным.
Так, например, поиск вхождений текста по семплам возвращает 0 при случае точного нахождения сэмпла в тексте, т.е.,
другими словами, происходит не просто задержка, а порча данных.
Так как утилиты мои же, то однажды я скомпилировал билды с отладочной инфой, с целью выяснить, на каком этапе происходят фризы.
Оказалось, что фризятся исключительно секции кода (delphi):
Код:
| if FindFirst() = 0 then begin repeat ... until FindNext(DirInfo)<>0; FindClose(Dirinfo); |
Зависает внутри FindClose (это стандартная функция, если что), после завершения обхода текущей папки/каталога.
Утилит много, и в каждой есть такая секция. Но в тех утилитах, в которых, по логике своей работы, до закрытия папки
через FindClose нет открытых на запись файлов - фризов нет, я проверял на сотнях одновременных скриптов.
А вот если до цикла есть открытый на запись файл - то даже при трёх скриптах уже можно поймать фриз на 1й-2й минуте работы.
В общем, выяснив это, и причину (Outpost) я смирился, решив проблему костылём (описывать не буду), который существенно снизил общее быстродействие.
Надо заметить, что утилиты были написаны ещё в бытность XP, и там совместно с outpost (3.0.543.431) всё работало как и должно по ТЗ.
Вопрос в другом.
Прочитал без малого все 100 страниц последней ветки, и понял, чего не хватало все эти годы:
отключить проактивку насовсем, т.е. вырезать. Как я теперь понимаю, это возможно.
Что сделано:
- Отключены хуки wl_hook.dll+wl_hook64.dll в реестре "AppInit_DLLs" по обеим веткам x64/WOW64,
- Отключена spae.dll через переименование (у меня тоже файл логов spae.log растёт очень быстро на обеих машинах с win7/win10)
- Отключены плагины .ofp через переименование файлов в папке plugins_acs:
downloader.ofp, improve_net.ofp, hips.ofp, sand.ofp,
- Отключен драйвер Sandbox64.sys через реестр HKLM\SYSTEM\CurrentControlSet\Services\SandBox
параметр "Start"=dword:00000004 (сервис/служба выключен)
- в файл machine.ini внесены изменения:
Поправьте, покритикуйте, если кто в теме, всё ли сделано для того, чтобы выпилить
проактивную защиту на корню, если это вообще возможно?