Waste of CPU cycles

[Guest]

[klemm]

Hello!

I generally like CPF very much.
The BSOD-s i have reported are gone with the latest version (2.4.18.124).

..and now the part why i'm posting - about what still could use some improvement

There is just one really annoying thing left - it uses way too much cpu for an application that is supposed to be always running.

Currently cpf.exe is spending 10-35% as reported by XP task manager. Total cpu time is around 6 hours! (uptime is 50 hours).

I have an Athlon 64 X2 4200+ CPU, 1GB of RAM, and RAID 5 disk system. Fresh install of XP.

I usually have uTorrent running. On average, the system has about 100 active connections.

I turned off ABA in CPF - no change.
I set security level to 'Allow all' - still 10-30%.
Only when i quit uTorrent, the usage drops to 0.

I think there are still some optimizations to be made...


BR,
Klemm

[soyabeaner]

It's the logging.  Try this thread: http://forums.comodo.com/index.php/topic,6933.0.html

[klemm]

Thanks for the tip!

I have been waiting to test it, but i can't: cpf.exe is using 1-2% cpu now.
Same conditions:
 - i have uTorrent running again.
 - Lot's of connections
 - CPF mode is set to 'Custom'
 - All except ABA are turned on

But no CPU hog.   

If it goes up again, then i can test is turning off logging makes any difference.


BR,
K

[soyabeaner]

klemm, I've been around the block when it comes to this issue.  The main reason is because of the logs.log file is constantly over-written with CFP's log data.  This write activity is what makes the 100% cpu for cpf.exe.  1-2% cpu is standard.

[klemm]

Not up to 30% yet, but it's slowly working it's way up there.  5 to 15% currently (started from 1-2 as i mentioned in my last post).

I turned off all logging. Set mode to 'Allow all'. No impact at all.

I don't think its the logging. 
It can't be the logging, unless the logging is seriously buggy. Writing a few kilobytes every second does not bring this kind of computer to its knees. I know. I've been developing applications for more than ten years.

Rather looks like some sort of logic leak to me. Memory use is around 11Mb and not growing.

Any other ideas?
Sure would like to help get this ironed out.


BR,
K

[soyabeaner]

For myself and others, it seems that setting logs.log to read-only works.

So cpf.exe, not cmdagent.exe, is still eating cpu?  Your issue is similar to ziopaper's here: http://forums.comodo.com/index.php/topic,6573.0.html

As you can see, my last suggestion was to file a ticket.  If you do, please keep us updated as I'm sure lots of users including myself would like to know.

[klemm]

I set the log file to read-only and cpf.exe (yes, always cpf.exe, cmdagent.exe has only logged 0:34:26 cpu hours) calmed down to almost acceptable 2-7%. The constant disk writes went away - i assumed these were caused by uTorrent but it turns out it was cpf logging.

The logging is implemented strangely. The log file grows to limit (5-10-15.. whatever you set) and then restarts. When limit is set to 5 mb, it rewrites the whole log almost every time. I would expect the file size to remain constant and scroll out old records but i guess thats not possible with the current log format (something html-like). There are many things that can be done to reduce log record size and the amount and size of each write. I think this area needs some attention from the developers.

I guess this issue is solved.. kind of anyway.


Another strange thing. I was getting a lot of timeouts while browsing the web. It kept getting worse and worse over the last 12 hours. Finally i had to retry about 10 times before a page would load. First thing i did was restarting the routers. Did not help. But then i closed CPF and now it always works. Is this a known issue too?


--
BR,
K

[soyabeaner]

The logs.log file was recently added in v2.4.  I think it's partly there as a backup and to resolve the issue that it didn't retain a copy after a reboot.  Here's the drawback to setting it to read-only: your logs in the GUI will only remain during CFP's active session.  It will reset to the last time you set it to read-only once CFP is exited.  That's why it's only a workaround that I discovered.

I'm sure logging will improve in v3, but I haven't seen any official word from the devs.

Web browsing timeouts?  I haven't seen any reports specifically described in your case.  You might receive greater feedback by starting a new topic on that one.

[klemm]

Oh darn!

It's was not the logging after all. I have logging turned off, logfile read-only and it's still bouncing up to 30% with average on 8%. Current memory usage is 25mb.

Yesterday it crashed with BSOD on inspect.sys. Unfortunately i had dumps turned off.


BR,
K

[soyabeaner]

Hmmm...that is rare to see it's not the logging.  In case you ever come across the BSOD again with minidump on: http://forums.comodo.com/index.php/topic,6747.0.html

[jharris1993]

The logs.log file was recently added in v2.4.  I think it's partly there as a backup and to resolve the issue that it didn't retain a copy after a reboot.  Here's the drawback to setting it to read-only: your logs in the GUI will only remain during CFP's active session.  It will reset to the last time you set it to read-only once CFP is exited.  That's why it's only a workaround that I discovered.

I'm sure logging will improve in v3, but I haven't seen any official word from the devs.

Web browsing timeouts?  I haven't seen any reports specifically described in your case.  You might receive greater feedback by starting a new topic on that one.

Here's a really stupid idea that might help (developers take notice!)

Is there a way to reduce the priority of log writes?  It seems that log writing is consuming a lot of processor cycles when it should be doing something else.  Perhaps the log data can be cached somewhere in memory?

Stupid idea #2:  Punt the HTML logs.  HTML in the logs is just eye-candy and it makes them more difficult to work with if you want to drop the bastid's in a text-editor.

My vote is ALWAYS for simple, plain-text logs.

If the logs are reduced to plain text, it makes administering them much easier.  Once the log hits max size, just add to it (as needed), then prune from the top. (I'm sure there's a way to create the equivelent of a circular buffer/pipeline/FIFO for text logs, but I haven't run across any file-structures books lately.)

What say ye?

Jim

[Tags:]