View Full Version : TeaTimer memory usage
Hello,
I think there is a problem with TeaTimer memory management. It uses more and more memory unless the system is restarted.
I have Windows XP Pro SP2. When started is uses 16260 KB, an hour later only 4416 KB. Then 24 hours later 44510 KB and 48 hours later 85028 KB !
As most people, I have BOINC manager with SETI@home project running. That's why my computer is allways on.
Best regards.
Well its 9.32am here, my teatimer stats:
1173 Blocked
1200k mem usage
Will check back in 6 hours to see what the usage is :)
I was wondering if somebody has found something about this "memory used"...
Here you can see after 48 hours (not using my computer) it uses over 140 MB of RAM !
http://www.ifrance.com/fschneider/TeaTimer.JPG
Boeing_737
2006-02-24, 18:29
You have to do some close-reading of the help-file of Taskmanager.
You should know how to read the information given in "Processes".
It's cumulative.
I don't think so !
In help the term Memory Used is (translated from french) :
"In the Task Manager, the workspace of the current process, expressed in kilobytes. The workspace in use corresponds to the number of pages which currently reside in memory"
So TeaTimer IS using 143 476 Kb of memory !
Boeing_737
2006-02-27, 11:53
You're right, I was wrong.
But to be at any help somehow, I give a http://www.codinghorror.com/blog/archives/000393.html link here.
And just as information the numbers in my Task Manager:
http://www.helpmij.nl/leden/boeing_737/images/TeaTimer.jpg
FredericLS
2006-03-01, 03:31
I too noticed this growing in size and have a temporary solution. Create a shortcut to TeaTimer.exe in your Spybot menu; I call mine Spybot TeaTimer. Whenever you notice excessive size of TeaTimer, go to the System Tray, right click, and select Exit Spybot-S&D Resident. The memory, excessive or not, is released as it closes. Then go to Start, All Programs, Spybot S&D, and click the new shortcut, Spybot TeaTimer in my case. It is restarted with it's normal size. All is well. Do something you know will cause the pop-up and you will see it works as usual.
Gafonator
2008-07-10, 15:01
I was frustrated teatimer eats up about 50Megs of memory while being resident. Some time ago it was about 5MB.
When I uninstalled SpyBot, deleted all traces of it in registry also manually and installed it again it had about 8 MBs in memory. I also found and deleted some registry key under Internet Zones - it was the one with A LOT of www pages and appears in whole registry two or three times.
Now it's back to 48MBs.
The state with 8MB lasted about a day. Don't exactly know what is going on - but this may help you people a bit.
drragostea
2008-07-10, 21:37
The OS must be pretty hot after running it for 48 hours non-stop :P.
For now, I have 29 processes and TeaTimer is using 17MB of memory.
Have you guys upgraded to Spybot-SD 1.6.0.30?
Did you remove the previous versions prior to upgrading?
I only......
notice high spikes that occur for a very short time but then they go down again. For some reason you and 2 other people are experiencing this issue where it stays that way. Did you perhaps upgrade without uninstalling the older spybot first? just wondering.
There are at least three separate threads on this subject now, see also
http://forums.spybot.info/showthread.php?t=30923
http://forums.spybot.info/showthread.php?t=30651
perhaps the forum moderator could look at combining them.
As it stands it appears that most XP users are experiencing what seems like unwarranted periods of sustained CPU activity when Teatimer is actived and also possible growth in the amount of memory used by Teatimer when the PC is run for long periods of time (leakage?).
Basically I think we are all now waiting for some official response on this subject.
for most cases appears that the people that had this issue, at least most not all, just upgraded instead of a full clean install. I wonder if that will make a difference....
wyrmrider
2008-07-14, 23:13
Has Spybotsandra chimed in on this issue yet
she has been saying to just overwite
and she may be right
always
or
in most cases
or
never
too early to tell
I see the issue more often when the system has been upgraded more than once- but that is just an observation not a fact
for most cases appears that the people that had this issue, at least most not all, just upgraded instead of a full clean install. I wonder if that will make a difference....
Unfortunately that's not correct,
The characteristics that I have described in posts about Teatimer in the 1.6.0.30 version are from multiple PC's where a fully clean install was used. ie. Unimmunise, untick Teatimer and browser helper, untick host file and browser startup page lock, then uninstall old version. Manually delete folders in both program and document areas, run spybot small fix. Reboot, then install new version, download updates after install has finished.
If you have a look at Teatimer using Process Monitor, you will see what it is doing for the period of time after it is started, before CPU activity drops back - it is indeed working very hard possibly to establish a large registry reference and it does this every time it is started. The length of the busy period will vary with the speed and processing power of the CPU etc.
Greyfox,
Along with what Patrick has stated in the other thread and your own mention of CPU processing power, there are other influences. For example, someone else mentioned a maximum of 60-70% utilization which is probably caused by either limited memory and/or disk system response. While Patrick feels that most of these things will occur very quickly, he's forgetting how badly many real PC hardware systems actually perform, so his own test systems may not reflect the real experience of many users. This is especially true if the test systems operate as virtual machines with lots of RAM, since these usually operate much faster.
My own experience with TeaTimer has been an increasing degradation in startup performance on my old Windows 2000 based PII 400, even with the 512MB RAM it contains. However, that system is obviously processor starved, so TeaTimer is simply another element within a 10 minute plus startup sequence that also includes the real-time antivirus and other normal processes. There's no mystery here, it's simply more of the same as Patrick's post makes clear, the question is how to safely reduce this normal overhead while maintaining the security that TeaTimer process/registry monitoring adds.
What I think is more obvious, but less noticed by most is that a major decision about continued support for the Win9x/ME family will need to occur, if it hasn't already. The recent issues with the outdated 1.3 version of SS&D and the decision to discontinue detection update support for older versions force users to either upgrade or give up on Spybot S&D. The requirements of the likely solution to the TeaTimer startup issue will only stress the resources of these systems further. A clear decision needs to be made as to whether future support for the Win9x OS is even reasonable, since these OS are basically dead and would require significant changes to the operation of current versions of SS&D to continue real support.
Bitman
Greyfox,
Along with what Patrick has stated in the other thread
http://forums.spybot.info/showthread.php?t=30994
Unfortunately that's not correct,
The characteristics that I have described in posts about Teatimer in the 1.6.0.30 version are from multiple PC's where a fully clean install was used. ie. Unimmunise, untick Teatimer and browser helper, untick host file and browser startup page lock, then uninstall old version. Manually delete folders in both program and document areas, run spybot small fix. Reboot, then install new version, download updates after install has finished.
If you have a look at Teatimer using Process Monitor, you will see what it is doing for the period of time after it is started, before CPU activity drops back - it is indeed working very hard possibly to establish a large registry reference and it does this every time it is started. The length of the busy period will vary with the speed and processing power of the CPU etc.
before i noticed ALOT of people have this problem, haha, but thanks for the correction. :)
Coronamaker
2008-07-15, 23:29
My experiences with the memory issue so far are that regardless of the system resources (RAM/CPU) or method of install (Upgrade or Clean Install) on all of the XP machines that I have put the 1.6 version on I have the same results. Upon completion of system start up, TeaTimer is typically using @ 27 MB which is better than the 46 MB most of my systems were usually at with the 1.5 version. FWIW I have not run into a creeping memory increase issue yet and I have been running this version through the Beta so maybe it is a conflict with other software.
If I use a memory cleaning program like Instant Memory Cleaner, that drops TeaTimer's memory use in Task Manager down to around 1.5-3.0 MB until the next time I launch an application at which time it hops back up to around 14.5 MB and stays there. Shutting down the application does not change the TeaTimer memory usage in Task Manager but re-running the memory cleaner again puts me back down to that same 1.5-3.0 MB roughly, and there it stays until I do something else. Not sure if there is a way to get TeaTimer to release that memory, but I am guessing it may result in an overall slowdown from having to release and then reload every time an application was launched. So now I just run a memclean after loading Windoze and let it use it's 14 MB.
wyrmrider
2008-07-16, 03:11
Interesting Corona
I'll try it with cacheman
wyrmrider
2008-07-16, 03:46
zerovlotage posts in the beta forum thread
responding here as his info in the other thread is valuable and do not wish to hijack it on a tangent
"Other programs with resident protection DO NOT take even longer. On systems where this problem exists, every other real-time solution works fine - only TT is showing spikes"
Counterspy shows exactly the same behaviour
spikes with at least two real time modules (active protection being one of them)
which can last a long time or forever
-with no way to stop except ctl>alt>del
and
if a scan is invoked "loading protection" can hang forever
i've let it run overnight without completion
happens after an update mostly
My experiences with the memory issue so far are that regardless of the system resources (RAM/CPU) or method of install (Upgrade or Clean Install) on all of the XP machines that I have put the 1.6 version on I have the same results. Upon completion of system start up, TeaTimer is typically using @ 27 MB which is better than the 46 MB most of my systems were usually at with the 1.5 version. FWIW I have not run into a creeping memory increase issue yet and I have been running this version through the Beta so maybe it is a conflict with other software.
Well, the main problem is not much the amount of memory used in the working set, even if I think that it is high, but the amount of dedicated memory, which is the sum of the working set (in physical memory) and the paged out memory:
The working set is effectively quite high during Windows startup (along with a quite high CPU usage which is a clear sign of lot of missing optimisations for performance, and one of the main cause why the Windows boot time is quite long (SpyBotSD's TeatTimer can consume more than half of the total CPU time, when all the other processes and services are starting), but after some time, it decreases to about 660KB no my system (I think it is still too high, even that this represents more than 20% of the remaining unused memory). Then this workign set restarts to grow, progressively over a period of about 24 hours, up to nearly 40MB, even when there's absolutely no interactive application running (with only a reduced set of the Windows services, from which I have disabled or about one fourth of all the services of Vista Integral Edition that I don't need, and configured nearly one third of the other services for Manual startup for running them only on demand).
It's true that Vista uses a lot of memory for the "netsvcs" services group and I don't know how to reduce it significantly (most probably, I should tweak some unknown parameters to reduce their internal buffering which is clearly excessive as well).
Howeer the main problem is the dedicated memory which constantly fills the paging file, up to the point that it can fill up. In order to avoid exhaustion of the paing file, I need to set it 3 times the total of physical memory, only because of SpyBotSD's TeaTimer. You may think that the fact that the working set correctly shrinks after some time is enough, but really the constantly growing dedicated memory in the paging file is the clear sign of memory leaks in TeaTimer, and it can explain why the dedicated memory also grows slowly after some time due to page fragmentation in the working set which is mostprobably full of very small memory fragments that will only be paged out after a long time.
After about 48 hours, the system performances start to be very quite slow, with slow displays of directory contents in the Widnows Explorer for example when scrolling long directories. I've tried to increase the throughput by flushing the icon/thumbnail cache or by disabling it, but this has no significant impact on the performance: the GUI becomes very sluggish, and some actions in Wnidows explorer take more and more time (displaying the content of the windows\system32 directory and scrolling it may then require more than noe minute, selecting an element with right-click can take up to one minute before it displays the contextual menu, sometimes not for the selected element. Deleting a file by selecting it and pressing the Delete key or using the Delete command in the context menu can become quite dangerous as it may unexpectedly operate on the wrong element (not the one that was selected first).
All this degradation of performances becomes unsupportable, just because of TeatTime filling most the remaining space in the pagnig file. Other effects include slow start of applications, incorrect default fonts displayed in web pages (I start loosing Chinese characters, then complex Asian scripts like Devanagri, then Arabic fonts...), or other CSS properties ignored (like background colors or images...).
I'm running Vista with 2GB RAM (however my processor is single core at 2GHz, something that should still be enough for Vista, even with the Ultimate Edition). Disabling Vista Aero or even all themes, or the transparent browsers has a very small impact which is insignificant for this case. All I can do is effectivel to exit TeaTime and restart it.
Given that I have an Antivirus that also includes its own antispyware, I wonder if it is only useful to run TeaTimer (given that I frequently get 2 or 3 alerts for the same modification of system settings: Windows Defender, My antivirus, and TeaTimer: this is excessive, and in fact I suspect that TeaTimer's memory management is not very clean if it cannot access immediately to some system information that is being accessed also by other antimalware tools running concurrently: in the case where TeatTime acnnot get an exclusive lock on the object to control, it seems that it yields and retries after waiting some time, but it forgets to release some of the termporary ressources used, such as internal buffers or structures needed to parse the content modified system item).
Given the fact that the memory usage is growing very slowly, I suspected that this could be handles to registry keys that are left open but leaked, or this could be handles to asynchronous IO event handlers or some other interprocess communciation handles (used between the SpybotSD TeaTimer's background service and the TeaTimer UI process that filters events and displays them when appropriate)
When I see just after boot time that the dedicaetd memory for TeaTimer alone is alerady one third of the total physical memory, TeaTimer really has a problem.
Antoher related problem is the initial time needed just after the first intallation or upgrade to perform the first full scan: on my system it took more than 1 hours and half ! Durnig that time, I could not even go to the preferences panel to check its settings (there's not even any way to dismiss this first scan before changing the settings, and if you attempt to cancel this initial scan run at program start, the program will freeze indefinitely and there's no other way to unfreeze SpyBotSD than killing it from the Tasks Manager: here there's clearly a bug in SpyBotSD: you shuold be able to cancel the initial scan performed before the SBSD UI is displayed without freezing the program indefinitely and without exiting immediately if I click the button to not perform a full system scan).
In terms of usability, SpyBotSD has become more and more memory hungry, and now it takes really too much time just for scanning one family of spywares that contains more than 100,000 signatures (apparently only in memory because there's no disk activity during that long time). This suggests that the signatures in SpyotSD are not compressed efficiently and SpyBotSD is constantly rescanning the same registry key too many times. This also suggests that the old scanning memory is now obsolete: SpyBotSD inspects each known Spsyware individually and is unable to merge the many similar signatures for a fast scan. This constributes to the constant degratation of SpyBot performances. Other antispyware tools are apparenty using a smarter compressed format for their database in order to avoid verifying the same places too many times.
My conclusion is that SpyBotSD is now facing a major problem due to its internal representation of its database: factorizing common signatures to checking only once the same registry entry is now an emergency, because the number of spywares to check is exploding. This cannot continue this way. There was a time when Spybot could perform a full system scan in about 5-10 minutes using its database. Now the database is so big with more than 440,000 malwares to inspect, than it has become unmanageable.
This system where each malware is scanned independantly of the others must find an end. You need a new database format, for reducing the full scanning time (consider inspecting the registry linearily, using a snigle index pointing to the possible list of malwares, then find the complete list of infection points by looking into an external database not permanently in memory (or only present in memory within a cache of reasonnable sizen, according to an MRU strategy). There is certainly now much less than 400 000 total points of infections in the registry, given that most malwares are trying to invade the same few locations.
There are tradeoffs to find to optimize it and this is a problem exactly similar to the problem of performing a join in a SQL database between two tables whose one is much larger than the other: even if this is logically equivalent, the loop that fullscans the greatest number of locations must be the inner loop, not the outer loop. Now it seems that this optimal order of loops is reversed: the outer loop is on the full list of malwares (440,000 and growing) and the inner loop is on the few locations that each malware is possibly trying to infect. Swap the loops so that SpyBot will scan the first the few registry locations that all malwares are trying to infect, then read the associated data from the registry of filesystem to get its value, then perform a lookup for the complete of possible malwares that may infect this location: this loop is probably much longer in terms of unique enumerated values than the previous loop on locations.
For inspecting the ActiveX classes, it seems that you need a separate index of the GUIDs used there: this index will point to the data associated to the small list of malwares that use this GUID, get this list from an external file source (on disk, not necerssarily in RAM) then inspect its contained elements, that are all possible infection locations in the registry or filesystem, filter out the items that have already been scanned (this requires that this list of locations is fully ordered in some way) and check the rest of the possible locations. To make this possible, you need a new format for the database index that must be ordered completely differently, to make the maximum benefit of its data compression.
SpyBotSd was a great program in the past, now it cannot sustain the exploding growth of known malwares. For TeatTimer itself, it does not need to perform a full check of all possible locations with indection data: TeaTimer should just be able to detect the few locations that the malwares need to indect in order to be functional, but it does not need to inspect all locations in the registry or on the filesystem, unless the critical locations needed by the malwares are found to be infected.
So:
(1) consider changing the database and indexing it in a more efficient way. This is exactly the same problem as optimizing the schema and queyres in a SQL relational database.
(2) investigate the memory leakages (notably the leakage of system handles that are left open if a critical section cannot get the necessary lock immediately). I think that most of these leaked handles are handles to registry keys (this is apparently confirmed by the total number of open handles which whose growth is nearly propertional to the growth of total dedicated memory (and most of them get pages out and never reused later). Too many handles also means that the dedicated memory for the System process is also growing in size for storing the system structures allocated in memory for storeing the attributes or data of an open handle (and this is happening as well).
(3) prioritize the scanning loop
(4) correct the program freeze when canceling a scan in progress performed when the program is started (but the main GUI window interface still not displayed): the scan should stop immediately but should not forbid opening the GUI interface to change some settings
(5) consider placing the SpyBotSD configuration panel in another program run separately from the rest of the interface. SpyBotSD must be fully configurable even if no scan has been performed still.
For now, all we can do is effectively exiting TeaTimer and restarting it.
Note that TeaTimer is considered by some serious antimalware tools (including Norton or AVG) to be itself a malware (not much because of what it performs or installs, but because of the uninformed choice that Spybot gives to users in case of a possible infection: delete key/file, heal file, or ignore the issue, a chioce that many users cannot do safely without errors, where the user may inadvertenty choose to ignore the issue, with no way to revert his decision to ignore the issue later: most of these chioces should be automatic ior should have reasonnable defaults)