ECELeader 2 Posted October 3, 2018 Posted October 3, 2018 I have noticed that ESET Service has a relative high CPU usage when using Windows Subsystem for Linux compared to other processes. Please see the attached screenshot where I use WLinux, a WSL distro from Microsoft Store. My System Specs are also attached. I am running latest version of ESET 11.2.63.0. System Specs.txt
Administrators Marcos 5,450 Posted October 3, 2018 Administrators Posted October 3, 2018 Does temporarily pausing real-time protection make a difference? If so, generate a Procmon log so that we can see what files are being accessed / scanned when cpu goes up. 6% utilization is not high, e.g. if a lot of files are actively being scanned.
ECELeader 2 Posted October 4, 2018 Author Posted October 4, 2018 (edited) 23 hours ago, Marcos said: Does temporarily pausing real-time protection make a difference? If so, generate a Procmon log so that we can see what files are being accessed / scanned when cpu goes up. 6% utilization is not high, e.g. if a lot of files are actively being scanned. First of all, I should note that Windows Subsystem for Linux (and consequently WLinux or any other Linux flavors that use it) is of great importance to me. I am studying computer engineering in a university and WSL is a great development tool allowing running Linux command-line tools directly on Windows. It is a shame discovering that ESET Internet Security, which is a product I admire and love, causing a slowdown when using it. WLinux includes a built-in script that automates and simplifies the installation of various developer tools (such as python3, node.js, vscode etc). With my preferences, after running the script, WLinux occupies approximately 2gb of space in disk. In order to compare the performance impact of ESET Internet Security, I run the same script with the same preferences two times, while previously resetting WLinux app through windows settings. Running the complete script with real-time protection disabled took about 14 minutes. Running the complete script with real-time protection enabled took about 33 minutes! Almost 20 minutes slowdown! I noticed that the there was a significant slowdown caused by high ESET service activity, when the script was unpacking packages and installing applications through the apt-get system. Though, the slowdowns caused by ESET are also noticable in various WSL functions like opening an application like code through X410. Here is a link to the generated Procmon log. I recorded all the events, while running the script with ESET real-time protection enabled. Because it took 33 minuted to finish, it was too big (1gb compressed) to post here so I uploaded to Mega. Also, I attach in this reply, the ESET settings I used, exported using ESET's import/export settings tool. eset settings.zip Edited October 4, 2018 by ECELeader
Most Valued Members Nightowl 206 Posted October 8, 2018 Most Valued Members Posted October 8, 2018 (edited) Why don't you install Ubuntu/Linux as Virtual Machine and use the terminal from there ? , instead of that software which emulates Terminal on Windows, But also if you feel that you don't want to stop using that software and not go for virtual machine , if you trust yourself with what you are doing in that emulator , then you can exclude it from being scanned till ESET provides you for a fix so you can use it fast while ESET is still monitoring your system. Edited October 8, 2018 by Rami Updated
ECELeader 2 Posted October 8, 2018 Author Posted October 8, 2018 (edited) 9 hours ago, Rami said: Why don't you install Ubuntu/Linux as Virtual Machine and use the terminal from there ? , instead of that software which emulates Terminal on Windows, But also if you feel that you don't want to stop using that software and not go for virtual machine , if you trust yourself with what you are doing in that emulator , then you can exclude it from being scanned till ESET provides you for a fix so you can use it fast while ESET is still monitoring your system. I used VM in the past, but WSL suits me better and I prefer it. There are several reasons to use WSL. For example: Bash interactions with windows programs. Run native Linux binaries without the overhead of a VM (WSL is not an emulator as you say, but it runs Linux binaries directly). WSL requires fewer resources (CPU, memory, and storage) than a full virtual machine (It uses only 2 gb of storage in my machine). WSL also allows you to run Linux command-line tools and apps alongside your Windows command-line, desktop and store apps, and to access your Windows files from within Linux. WSL enables you to use Windows apps and Linux command-line tools on the same set of files if you wish. It is very useful for developers, because you can use developing tools from both worlds (Windows and GNU/Linux) on the same files without dual-booting or transferring files to the VM. You can even shift+right-click in Explorer and open bash quickly in the current directory with "Open Linux Shell here" option. For me, these conveniences are enough to switch from VM/dual booting to WSL. I don't prefer to exclude WSL from being scanned and I believe it won't reduce system impact either, because each program that runs through WSL is executing directly on Windows (as shown above in the screenshot of task manager) so I will have to exclude every single user/Linux program-package I use in WSL separately in order to reduce system impact, which is not ideal. I think this is an issue that could affect many people, especially in the future where WSL may be adopted by other people. So I think it is wise to bring this issue to ESET and find a solution for this problem before it affects other people. Edited October 8, 2018 by ECELeader
Most Valued Members Nightowl 206 Posted October 8, 2018 Most Valued Members Posted October 8, 2018 Thanks for telling me about WSL , I never heard of it before , I was just trying to help you with my suggestions but it seems that I didn't , well atleast I learned something and I will take a look at WSL.
ECELeader 2 Posted October 8, 2018 Author Posted October 8, 2018 (edited) No problem, I also try to learn something new every day. There is always something new to learn Also, thanks for your interest in helping me?. I just hope ESET will take a look at this. Edited October 8, 2018 by ECELeader
jdashn 12 Posted October 8, 2018 Posted October 8, 2018 Just curious, you're having the slowdown during the app-install script, or are you seeing slowdown using wsl in general? Jason
ECELeader 2 Posted October 8, 2018 Author Posted October 8, 2018 (edited) Yes i notice slowdown using wsl with eset in general. I notice a slowdown when starting/executing applications, compiling etc. Though slowdown is most prevalent during apt-get operations and dpkg but it is not limited to it. With protection disabled wsl feels overall snappier. For example when compiling a simple small project written in C with gcc I can prove that with real time protection OFF the compilation process is about 30% faster! This is a small project. Imagine when compiling a larger project, a slowdown penalty of 30% would matter a lot! I measured the compilation of the project 3 times for consistency with protection OFF and Protection ON. (We observe that each time I compile the project the compilation time is shorter due to OS/hardware optimizations like caches, TLB etc but with Protection ON is always about 30% slower) Edited October 8, 2018 by ECELeader
Administrators Marcos 5,450 Posted October 9, 2018 Administrators Posted October 9, 2018 I didn't find anything unusual with regard to ESET. Ekrn spent 14,5s on the file C:\Users\ntona\AppData\Local\Packages\WhitewaterFoundryLtd.Co.16571368D6CFF_kd1vv0z0vy70w\LocalState\rootfs\lib\x86_64-linux-gnu\libc-2.27.so but other processes spent more than 700s on it. Does excluding the folder C:\Users\ntona\AppData\Local\Packages from scanning make a difference?
Hpoonis 7 Posted October 9, 2018 Posted October 9, 2018 Never used Win Linux. It seems like blasphemy. I prefer CYGWIN.
ECELeader 2 Posted October 9, 2018 Author Posted October 9, 2018 (edited) 5 hours ago, Marcos said: I didn't find anything unusual with regard to ESET. Ekrn spent 14,5s on the file C:\Users\ntona\AppData\Local\Packages\WhitewaterFoundryLtd.Co.16571368D6CFF_kd1vv0z0vy70w\LocalState\rootfs\lib\x86_64-linux-gnu\libc-2.27.so but other processes spent more than 700s on it. Does excluding the folder C:\Users\ntona\AppData\Local\Packages from scanning make a difference? The procmon log I posted in my first reply was not about gcc but was captured during apt-get install commands. I captured a new Procmon log when compiling a test project (see attachment in this post). I tried excluding the folder C:\Users\ntona\AppData\Local\Packages and It actually makes a difference, speeding things up. Is it safe to have all the contents of this folder excluded? It would be better if there wasn't the need to exclude the whole folder though. Logfile GCC slowdown.zip Edited October 9, 2018 by ECELeader
Administrators Marcos 5,450 Posted October 9, 2018 Administrators Posted October 9, 2018 4 hours ago, ECELeader said: The procmon log I posted in my first reply was not about gcc but was captured during apt-get install commands. I captured a new Procmon log when compiling a test project (see attachment in this post). There's nothing unusual. The CPU utilization by ekrn was very low all the time:
ECELeader 2 Posted October 9, 2018 Author Posted October 9, 2018 5 minutes ago, Marcos said: There's nothing unusual. The CPU utilization by ekrn was very low all the time: ekrn had also a very high number of file event in the same procmon I posted above. I run sysbench fileio sequential read/write test on wsl and noticed that when eset protection is not off/or the folder C:\Users\ntona\AppData\Local\Packages is not excluded from scanning there is a latency in read/write operations. Also i do not trust the CPU utilization because I am running the October update of Windows 10 1809 and I read that there is a bug where CPU % is reported falsely. The important thing is that in real world usage there is a slowdown caused by ESET in various WSL operations. If you install a free version of WSL like Ubuntu you can test it. With ESET protection off or the folder excluded it performs noticeably faster.
7f5ad837 0 Posted October 11, 2018 Posted October 11, 2018 (edited) Just registered to chime in on this issue as well, since I'm experiencing the same behaviour: Constant CPU utilisation of around 30% from ESET with WSL running. Instead of excluding the entire "%userprofile%\AppData\Local\Packages" directory, I'm working around this by only excluding "%userprofile%\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs". Admittedly this is still not exactly ideal, but it's a slightly more targeted approach at least. It might be interesting to further restrict exclusion rules to hone in on specifically "offensive" files/directories. (It's not just "bin", since only excluding that still leads to high CPU usage.) Edited October 11, 2018 by 7f5ad837 Fixed typo.
ECELeader 2 Posted October 11, 2018 Author Posted October 11, 2018 3 hours ago, 7f5ad837 said: Just registered to chime in on this issue as well, since I'm experiencing the same behaviour: Constant CPU utilisation of around 30% from ESET with WSL running. Instead of excluding the entire "%userprofile%\AppData\Local\Packages" directory, I'm working around this by only excluding "%userprofile%\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs". Admittedly this is still not exactly ideal, but it's a slightly more targeted approach at least. It might be interesting to further restrict exclusion rules to hone in on specifically "offensive" files/directories. (It's not just "bin", since only excluding that still leads to high CPU usage.) Excluding only the Canonical folder for Ubuntu in "%userprofile%\AppData\Local\Packages" or the corresponding WhitewaterFoundry for WLinux seems to work for me also. As you say this solution is far from ideal. We are now at least 2 people experiencing this issue so it can't be a coincidence. Eset should take a look at this.
Recommended Posts