Teatimer - Memory

X

xonnected

New member
I've just recently updated Spybot S+D ready for a search; it's been a good few weeks since I last had chance, and since updating i've found that Teatimer takes up more and more memory on my PC, at times going above 80,000 K, and it dawned on me over the last year or two it's been on the up since being a small program that ran in the background with little or no lag on my PC. I'm not on a new system by any means; currently struggling on with 512MB waiting until the current economical climate gets better before I can upgrade, but i've used Spybot on more modern systems (Athlon64 Dual Core with 1GB RAM) and had similar issues.

Is there any reasons why this might be happening or anything I could do to prevent it? I was for a while debating disabling teatimer but I feel that my PC might be vulnerable to attacks if I did, and I haven't found an equivalent piece of software that would be able to block registry attacks effectively.
 
This has been discussed before but all the threads arrived at the same conclusion: this is what TeaTimer is doing (actively protecting you) and that's the resources it'll need.

On more modern machines that are well equipped with 1-4-GB of RAM, a process using up 80-120MB of RAM should be nothing. The system will operate just as smoothly. TeaTimer will usually consume around 30-50MB of RAM and the resource usage will increase gradually if the computer is not rebooted between periods of usage. 512MB of RAM might be enough for TeaTimer to operate without lag, but this might not be true depending on the processes that run on your machine.
 
I do not consider it normal.

The attached jpeg shows that TT allocated 80mb in RAM and 80mb virtual memory, and on top of that it's using 50% CPU. The image was taken 10 minutes after computer startup, now it's 30 minutes and it's still firing on all cylinders without any indication it is going to stop.

There is something inherently flawed in the coding of TT if it takes that much RAM. A C++ class somewhere has to be reviewed.

It managed to read 355 MB from the hard drives in 4 minutes, so it is scanning my entire machine, what for?
 
The high CPU load continues on my machine for days now.
I am beginning to suspect that TeaTimer is some kind of bot, otherwise what is it doing using 1GHz for several days? It used 26 hours worth of CPU time by now.
 
It's actually not a "C++ class", but a thing in the memory manager itself that is using up too much memory / not freeing some (ironically one we picked because it was a special memory leak detection one, not knowing it had one itself) - we'll switch the memory manager soon now that we found that.

And TT scans all running processes, if those are 355 MB in size, well, it scans the original files in addition to the memory as well. It'll cache results at least until the next update, so it won't always take up that much.
 
Still going.

PepiMK said:
And TT scans all running processes, if those are 355 MB in size, well, it scans the original files in addition to the memory as well. It'll cache results at least until the next update, so it won't always take up that much.
Click to expand...

To the moment it read 122 GB from the disks. I most certainly do not have that much in executables.
 
122 GB different data or accesses to the same files maybe?

It regularly reads from a 3 MB and a 7 MB database file -always just a few bytes (around 160 bytes probably), but if your counts include always the full file size, that may um up. Still would need 12.200 processes to be checked, which are more than most regular machines see in weeks of running (depends of course, a webserver spawning instances of a process for each client would probably easily reach that within hours or a day).
 
PepiMK said:
122 GB different data or accesses to the same files maybe?

It regularly reads from a 3 MB and a 7 MB database file -always just a few bytes (around 160 bytes probably), but if your counts include always the full file size, that may um up. Still would need 12.200 processes to be checked, which are more than most regular machines see in weeks of running (depends of course, a webserver spawning instances of a process for each client would probably easily reach that within hours or a day).
Click to expand...

It seems that I was able to find the root cause last night.
After killing all but necessary system processes, I began starting the usual tasks one by one, and as soon as I started Serv-U FTP server, the show began. It seems that SB treats Serv-U as a virus of some sort and does something about it. Kaspersky identifies Serv-U as a threat-not-a-virus, whatever it means.

How can I find what exactly SB does with Serv-U daemon?
 
You must log in or register to reply here.
Back
Top