aMule Forum
English => Multiplatform => Mac OSX => Topic started by: dashaund on November 02, 2005, 05:58:23 AM
-
Didn't see this one posted recently, so I thought I would. I'm experiencing an extremely high CPU load with aMule right now. I tried the preconfigured binary (10-06) and downloaded the CVS binary (11-01), and both versions have the same result; aMule maxes out my cpu to 100%. I have debug on, so if you guys need someting, tell me and I'll send it. The weird thing is that it just started doing this. The 10-06 build didn't do this in the past. I THINK it might have something to do with the recent Mac OSX 10.4.3 system update. Anyone else seeing this?
-
Recent CVS builds exhibit a high cpu utilization here, too. It usually takes a couple hours for this to happen but then amule reaches ~100% and stays there. Since I'm running 10.3.9 I think we can rule out that it is related to the recent 10.4.3 update.
Speaking of 10.4.3, can you run amule for a few hours and then do "netstat -aLp tcp | grep -w 4662" (with 4226 being your amule tcp port) in the terminal? I would be very interested in the output.
I've been working with ken now for a while on tracking down the memory corruptions that make amule relatively unstable, so I haven't had time to investigate the cpu load issue further.
Could you try to get a better idea of the time course of this issue? That would be really great. For instance, it would be interesting to know whether the increase is gradual or sudden and how long it usually takes. :)
-
The high CPU load only lasts for the first 5-10mins on startup, and then goes away. I'm assuming it maxes out while initally connecting to servers/peers/Kad, etc... When I run netstat I get:
0/0/5 *.9662
Being, my aMule TCP port is 9662. Let me know if I can be more of a help.
-
If it's right after startup, it could also be amule hashing files.
I guess, I need to do a more systematic investigation on the high cpu load issues on my machine. Problem is, I've compiled about 40 different amule versions over the last four weeks with various patches while hunting the memory corruption, so I kinda lost track under which circumstances i was experiencing the high cpu load. ;)
0/0/5 *.9662
This is very excellent as it indicates that Apple really did fix the stuck connections issue, that Tiger users were suffering from. So from now on I can post unpatched amule binaries again. :)
-
Here's a way to provide us more information to help us figure out what's going on. When aMule is using lots of CPU, open a Terminal window (Applications -> Utilities -> Terminal) and type the command:
sample amule 10
and post the resulting file to this thread.
Thanks for you help. :)
-
Okay, I ran it, and the attacthment is what I came up with. I had to .zip it because it was too big...go figure.
-
OK, that was big. ;)
One thing I noticed is that one of the culprits in using the CPU time is code in Kad that was just recently made more efficient (thanks to lupz). So, the next CVS snapshot or release should improve in that regard.
The second thing is that this looks like it's right during aMule's startup. Which I guess is what you are reporting. Well, ideally we wouldn't want aMule to be quite so hungry even during startup, but you should understand that it's doing a lot of setup work right then. So, some high rates of CPU use are to be expected.
If it keeps using high CPU after you think it should be fully initialized and settled down, we'll re-examine the issue.
-
Yeah, I understood that it is going to use a lot of CPU cycles at startup...that's just common sense. I was just concerned about the fact that it seems to temporarily handcuff the interface with the 100% load, then it tapers off and everything is fine. I'll download the nightly and see if everything if okay. I really appreciate the hard work you guys invest in this project. It is truly one of the premier open source projects out there!
-
I just noticed amule taking up 100-120% CPU time on my dual G4 1.8ghz (after running for ~ 24h). I'll keep an eye on it but I would be surprised if CPU usage went down again without restarting amule. I've attached the output from 'sample'.
[rev 5636 // wx cvs 2005-11-03 // ken's latest anti-memory corruption patch]
-
Hmm. Well, I don't see anything obvious in the sample. aMule is spending its time doing all sorts of different things. There's no one thing that seems to be taking an inordinate amount of time.
If this happens again, it will be good to check other samples. Maybe a pattern will emerge.
Out of curiousity, is this the aMule session that crashed on quit? If so, it might be a symptom of the same underlying problem (memory corruption?).
-
I think I closed amule (without experiencing a crash) an hour or so after after I pulled out the samples, but I'm not 100% sure.
It seems like once the CPU usage is high it really stays that way until you quit amule. If you think it would be helpful, I can take a sequence of samples (say every 10min or so) once the CPU load is high again.
In any case, I will have a close eye on the potential relationship between the high CPU load and the memory corruption crashes on quit.
-
had the same problem. if this post is still an issue: i switched off the options containing "high cpu load".
-
Ken, just a quick update:
It's definitively not the Tab Info thing -- as I mentioned earlier, I did a test where I turned off all those (frequently) updated info things in the GUI (including "show transfer speeds in title bar" etc.) and aMule is still maxing out my CPU.
I shark'ed a bit more but I didn't discover any smoking gun. But then again, that does not have to mean much.
Right now I'm testing if I get the same effect using an older version of wx (namely 2.6.2). Let's see how that goes...
-
Fellow Mac users, ;)
are you experiencing excessive CPU utilization with the aMule CVS binaries, too?
I don't seem to get it if I only download a handful of files, but whenever I download 20-30 files with a number of popular ones among them, aMule completely maxes out my CPUs (dual g4 1.8gz). It would be very helpful to us to know if this is a universal effect of it is limited to certain system variables (e.g., only dual processor machines, only 10.3, etc.).
A simple tool for tracking your overall CPU usage is MenuMeters (http://www.versiontracker.com/dyn/moreinfo/macosx/17713). When you notice that your CPU load is high, you can go to Applications->Utilities->Activity Monitor to see if indeed aMule is the culprit.
Your feedback on this is highly appreciated. :)
-
hi!
i've tried the latest cvs-build (aMule-Mac.CVS.2005-12-21.debug.zip) and there is no indication excessive cpu utilization on my machine. i've also downloaded 20-30 files. the cpu load raises partly to 100%, however only some seconds. Afterwards everything made a normal impression (see attachment).
my system:
g4 1.4 ghz (mac mini) with mac os x 10.3.9
-
Fellow Mac users, ;)
are you experiencing excessive CPU utilization with the aMule CVS binaries, too?
I don't seem to get it if I only download a handful of files, but whenever I download 20-30 files with a number of popular ones among them, aMule completely maxes out my CPUs (dual g4 1.8gz). It would be very helpful to us to know if this is a universal effect of it is limited to certain system variables (e.g., only dual processor machines, only 10.3, etc.).
A simple tool for tracking your overall CPU usage is MenuMeters (http://www.versiontracker.com/dyn/moreinfo/macosx/17713). When you notice that your CPU load is high, you can go to Applications->Utilities->Activity Monitor to see if indeed aMule is the culprit.
Your feedback on this is highly appreciated. :)
I just posted this in another thread, but after reading this thread, I'm posting it here now:
I just switched to this new version, from previously using 2.1.3.
With the 2.1.3, I had a problem where Amule would overload my cpu if I was downloading many files at once (15 or so for example). Unfortunately now with this new version it still does the same thing. My Activity Monitor claims that Amule, when in this state, is using up to 150% of my cpu (don't ask me how that's possible!), and my fan is going quite fast!
(Usual condition Amule is using only 16% of cpu)
With the old version, the problem only resolved when Amule automatically stopped all downloads, then they all went from "Downloading" to "Waiting". (This seems not a good final solution!) It seems perhaps this new version is the same?
I have a Macbook, processor is 2GHz and memory 2GB.
OSX 10.4.11
The only reason I actually upgraded to this CVS version was because of this problem!
So, is there something I am doing wrong? Could this be due to something I filled in wrong in Preferences?
Thanks!
P.S I now realize this new CVS version does this overload trouble much more often than the old 2.1.3 version!
-
That is odd, to say the least. I consider Mac vastly superior to PC, and yet, how can this happen? I am able to download lots of files without trashing my CPU. This is not very efficient, but hey, I can do it. And my pc is rather old.
Some Mac users have been complaining about zlib, that aMule spends most of its time inside it. Maybe the zlib implementation has something different on Macs?
I believe it is time for the Mac people to do some profiling, so that we can focus on the real problem. I use callgrind here to profile, and it is very good. I bet Mac has something even fancier :)
Cheers!
-
Here's a way to provide us more information to help us figure out what's going on. When aMule is using lots of CPU, open a Terminal window (Applications -> Utilities -> Terminal) and type the command:
sample amule 10
and post the resulting file to this thread.
Thanks for you help. :)
I followed the above instructions (my Activity Monitor saying Amule cpu usage at 140%). And it gave this:
Sampling process 3981 each 10 msecs 1000 times
Sample analysis of process 3981 written to file /tmp/amule_3981.sample.txt
I can't find that file "amule_3981.sample.txt" anywhere. I searched for it with spotlight and there are no results. I don't even understand where or which the "temp" folder it's meant to be in is. Does it mean there is a temp folder at root level? I can't find it.
Any help please?
Thanks
-
Well, I can't say much about Mac, but I know it has some BSD code, so unix systems usually have a tmp directory at the root level that gets erased every boot. The file should be there, unless Macs place restrictions on normal users reading this directory. Maybe try as supervisor?
-
Yes, if you go in the terminal you can type "open /tmp/amule_3981.sample.txt" to open the file, or "open /tmp" to open a Finder window.
Even better would be to type "sample amule 10 -file sample.log", that should be placed in your home folder, if you do it in a new Terminal session.
(From another thread, but better to move the discussion here)
A little bit too high... It is true that most packets are compressed, but I did not know that the percentage would be so high. I don't know if there is a solution for that.
EDIT: BTW, you profiled CPU with wireshark?
No, it's called Shark. If I take an educated guess, it's just a GUI version of sample. I haven't really tried it before, so I don't really know anything about it.
-
Nice, when you have some results, please post them!
Cheers!
-
Okay I managed to open to text:
Analysis of sampling pid 3981 every 10.000000 milliseconds
Call graph:
1000 Thread_0f27
1000 start
1000 _start
1000 main
1000 wxEntry(int&, wchar_t**)
1000 wxAppBase::MainLoop()
1000 wxEventLoopManual::Run()
1000 wxEventLoop::Dispatch()
1000 wxApp::MacDoOneEvent()
1000 wxApp::MacHandleOneEvent(void*)
1000 wxMacProcessNotifierAndPendingEvents
1000 wxAppConsole::ProcessPendingEvents()
1000 wxEvtHandler::ProcessPendingEvents()
1000 wxEvtHandler::ProcessEvent(wxEvent&)
1000 wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
1000 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
1000 CamuleApp::OnCoreTimer(CTimerEvent&)
1000 CUploadQueue::Process()
746 UploadBandwidthThrottler::GetNumberOfSentBytesSinceLastCallAndReset()
746 wxMutexInternal::Lock()
746 MPEnterCriticalRegion
746 semaphore_wait_signal_trap
746 semaphore_wait_signal_trap
254 UploadBandwidthThrottler::GetNumberOfSentBytesOverheadSinceLastCallAndReset()
254 wxMutexInternal::Lock()
254 MPEnterCriticalRegion
254 semaphore_wait_signal_trap
254 semaphore_wait_signal_trap
1000 Thread_1003
1000 _pthread_body
1000 PrivateMPEntryPoint
1000 wxThreadInternal::MacThreadStart(void*)
1000 UploadBandwidthThrottler::Entry()
998 CClientTCPSocket::SendControlData(unsigned, unsigned)
994 CEMSocket::Send(unsigned, unsigned, bool)
881 CEncryptedStreamSocket::Write(void const*, unsigned)
881 CSocketClientProxy::Write(void const*, unsigned)
564 wxMutexInternal::Unlock()
554 MPYield
553 TSYield
552 swtch_pri
552 swtch_pri
1 sched_yield
1 sched_yield
1 sched_yield
1 sched_yield
8 MPExitCriticalRegion
4 RetrieveDataFromOpaqueID
2 pthread_mutex_unlock
2 pthread_mutex_unlock
1 RetrieveDataFromOpaqueID
1 TSLockMutex
1 __spin_lock
1 __spin_lock
2 TSLockMutex
2 pthread_mutex_lock
2 pthread_mutex_lock
2 pthread_mutex_unlock
2 pthread_mutex_unlock
2 TSYield
2 TSYield
309 wxSocketBase::Write(void const*, unsigned)
309 wxSocketBase::_Write(void const*, unsigned)
305 GSocket::Write(char const*, int)
173 GSocket::Send_Stream(char const*, int)
136 signal
136 syscall
136 syscall
33 sendto
33 sendto
2 GSocket::Send_Stream(char const*, int)
1 _sysenter_trap
1 _sysenter_trap
1 cerror
1 __error
1 __error
126 GSocket::Enable(GSocketEvent)
123 CFSocketEnableCallBacks
110 __CFSocketEnableCallBacks
108 sendto
108 sendto
1 __CFSocketEnableCallBacks
1 _sysenter_trap
1 _sysenter_trap
9 __spin_lock
9 __spin_lock
2 send
2 send
1 CFArrayGetCount
1 CFArrayGetCount
1 CFDataGetLength
1 CFDataGetLength
2 __spin_lock
2 __spin_lock
1 spin_lock
1 spin_lock
2 CFSocketEnableCallBacks
2 CFSocketEnableCallBacks
2 signal
2 signal
1 GSocket::Write(char const*, int)
1 send
1 send
2 wxSocketBase::_Write(void const*, unsigned)
1 __error
1 __error
1 __i686.get_pc_thunk.bx
1 __i686.get_pc_thunk.bx
3 CSocketClientProxy::Write(void const*, unsigned)
2 MPYield
2 MPYield
2 wxMutexInternal::Lock()
2 MPEnterCriticalRegion
1 RetrieveDataFromOpaqueID
1 pthread_mutex_unlock
1 pthread_mutex_unlock
1 TSLockMutex
1 pthread_mutex_lock
1 pthread_mutex_lock
1 wxSocketBase::_Write(void const*, unsigned)
1 wxSocketBase::_Write(void const*, unsigned)
68 UploadBandwidthThrottler::QueueForSendingControlPacket(ThrottledControlSocket*, bool)
58 wxMutexInternal::Unlock()
55 MPYield
55 TSYield
54 swtch_pri
54 swtch_pri
1 sched_yield
1 sched_yield
2 MPExitCriticalRegion
2 RetrieveDataFromOpaqueID
1 TSLockMutex
1 __spin_lock
1 __spin_lock
1 __spin_lock
1 __spin_lock
1 wxMutexInternal::Unlock()
9 wxMutexInternal::Lock()
8 MPEnterCriticalRegion
4 TSLockMutex
2 pthread_mutex_lock
2 pthread_mutex_lock
1 TSLockMutex
1 spin_lock
1 spin_lock
3 MPEnterCriticalRegion
1 RetrieveDataFromOpaqueID
1 RetrieveDataFromOpaqueID
1 TSSelf
1 TSSelf
1 MPEnterCriticalRegion
1 MPEnterCriticalRegion
37 wxMutexInternal::Unlock()
33 MPYield
33 TSYield
33 swtch_pri
33 swtch_pri
4 MPExitCriticalRegion
1 RetrieveDataFromOpaqueID
1 TSLockMutex
1 pthread_mutex_lock
1 pthread_mutex_lock
1 TSLockMutex
1 pthread_mutex_lock
1 pthread_mutex_lock
1 __i686.get_pc_thunk.bx
1 __i686.get_pc_thunk.bx
1 spin_lock
1 spin_lock
4 wxMutexInternal::Lock()
2 MPEnterCriticalRegion
1 RetrieveDataFromOpaqueID
1 TSLockMutex
1 pthread_mutex_lock
1 pthread_mutex_lock
1 pthread_mutex_unlock
1 pthread_mutex_unlock
1 TSSelf
1 TSSelf
1 __i686.get_pc_thunk.bx
1 __i686.get_pc_thunk.bx
3 CEMSocket::Send(unsigned, unsigned, bool)
1 GSocket::GetError()
1 GSocket::GetError()
1 CEMSocket::GetNextFragSize(unsigned, unsigned)
1 CEMSocket::GetNextFragSize(unsigned, unsigned)
1 GetTickCount()
1 GetTickCount()
1 UploadBandwidthThrottler::QueueForSendingControlPacket(ThrottledControlSocket*, bool)
1 UploadBandwidthThrottler::QueueForSendingControlPacket(ThrottledControlSocket*, bool)
1 __i686.get_pc_thunk.bx
1 __i686.get_pc_thunk.bx
2 UploadBandwidthThrottler::Entry()
1000 Thread_1103
1000 _pthread_body
777 select
777 select
177 __CFSocketManager
93 CFRunLoopWakeUp
92 __CFSendTrivialMachMessage
52 mach_msg_destroy
50 mach_port_deallocate
47 mach_msg_trap
47 mach_msg_trap
3 mach_port_deallocate
2 mach_msg_destroy
34 mach_msg_trap
34 mach_msg_trap
2 mach_msg
2 mach_msg
2 mach_port_deallocate
2 mach_port_deallocate
1 0xa0011ac8
1 0xa0011ac8
1 __CFSendTrivialMachMessage
1 mach_msg
1 mach_msg
31 recvfrom
31 recvfrom
28 __CFSocketManager
5 CFArrayAppendValue
4 _CFArrayReplaceValues
3 _CFArrayReplaceValues
1 CFAllocatorAllocate
1 CFAllocatorAllocate
1 __CFTypeCollectionRetain
1 __CFTypeCollectionRetain
5 CFArrayGetValueAtIndex
5 CFArrayGetValueAtIndex
5 CFArrayRemoveAllValues
4 __CFArrayReleaseValues
2 __i686.get_pc_thunk.bx
2 __i686.get_pc_thunk.bx
1 malloc_zone_free
1 malloc_zone_free
1 szone_free
1 szone_free
1 malloc_zone_free
1 malloc_zone_free
2 CFArrayGetCount
2 CFArrayGetCount
2 CFDataGetBytes
2 __memcpy
2 __memcpy
2 CFDataGetLength
2 CFDataGetLength
2 __CFSocketCopyRunLoopToWakeUp
1 CFArrayGetCount
1 CFArrayGetCount
1 __CFSocketCopyRunLoopToWakeUp
2 __spin_lock
2 __spin_lock
30 getsockopt
30 getsockopt
12 __spin_lock
12 __spin_lock
2 recv
2 recv
1 0xa0815050
1 0xa0815050
1 memset
1 memset
1000 Thread_1203
1000 _pthread_body
1000 PrivateMPEntryPoint
1000 wxThreadInternal::MacThreadStart(void*)
1000 CTimerThread::Entry()
1000 wxSemaphoreInternal::WaitTimeout(unsigned long)
1000 semaphore_timedwait_trap
1000 semaphore_timedwait_trap
1000 Thread_1303
1000 _pthread_body
1000 CMMConvTask(void*)
1000 pthreadSemaphoreWait(t_pthreadSemaphore*)
1000 semaphore_wait_signal_trap
1000 semaphore_wait_signal_trap
Total number in stack (recursive counted multiple, when >=5):
8 TSLockMutex
7 __spin_lock
6 MPEnterCriticalRegion
6 RetrieveDataFromOpaqueID
6 pthread_mutex_lock
5 __i686.get_pc_thunk.bx
5 wxMutexInternal::Lock()
Sort by top of stack, same collapsed (when >= 5):
semaphore_wait_signal_trap 2000
semaphore_timedwait_trap 1000
select 777
swtch_pri 639
sendto 141
syscall 136
mach_msg_trap 81
recvfrom 31
getsockopt 30
__CFSocketManager 28
__spin_lock 28
pthread_mutex_lock 8
__i686.get_pc_thunk.bx 6
pthread_mutex_unlock 6
CFArrayGetValueAtIndex 5
mach_port_deallocate 5
-
Does it help? I have no idea what it means.
Justin
-
Hi Justin,
It helps. Would be better if you analise it in a graphical program, but this is ok.
You need to have control over the start and stop of the profiling. You must start when aMule starts eating CPU and leave it for a while, and then stop profiling so that we have an idea of the routine responsible for it.
Cheers!
-
Hi Justin,
It helps. Would be better if you analise it in a graphical program, but this is ok.
You need to have control over the start and stop of the profiling. You must start when aMule starts eating CPU and leave it for a while, and then stop profiling so that we have an idea of the routine responsible for it.
Cheers!
Hi Phoenix
I have no idea what you just said, but it sounds encouraging. Could you tell me exactly what to do? And I will try to follow your instructions, and post here the results. I am using a Mac. I am quite computer-ignorant, but rather good at following instructions, be they logical.
Thank you!
-
It's doing it again (well over "100%" cpu usage. If you could instruct me, I could get you that readout you wanted.
-
Hi Justin,
Like I said before, I am no Mac expert and I do not own a Mac. This is most sad, I know... :P
That said, I have a limitted capability of helping, what I will try to do is to give you general instructions, but I have no means of actually testing what I will tell you. Of course I have done this procedure in other platforms with other programs.
The "profiler" is a program that builds a graph that represents the amount of time that the program stays in certain routines. It does that by periodically waking up and looking at the process that is beeing profiled and taking note of the "stack". The stack will tell where the program is executing.
So, in order to be precise, you need a way to start and stop the profiling process, so that only the times during the problem will be taken into account. If you profile your program for, say, 14 days, and during that time the program misbehaved for like 30 minutes, it is unlikely that this time is enough to show on a 14 histogram.
Lets say you have a tool named "prof". You would probably have to run your program like this:
$ prof amule
Of course, this is not an actual existing program, other tools do it other way, I am just trying to explain the general idea. This tool must have another program, or even the same executable, that will control the start and stop of data collection (profile). So, in another window you would need to do something like:
$ proftool start
wait some time...
$ proftool stop
At the end of this process, a file will be generated with the collected data. And usually a graphical front-end will be used to read the data in the form of a histogram. This histogram will tell you how much time the program has spent in each routine.
Of course, the Mac way is graphical and I am sure that Mac has a fancy GUI to do that, you need to read the docs of the program you are using, but this is the general idea.
-
If I understand phoenix post right, then it's probably the application Shark that you want to run. Try to do a spotlight query for it.
If you don't find it, then you need to install the Developers Tools, that's on the install DVD that came with your machine, or the Leopard DVD if you have bought that. Install that from the Leopard DVD, if you have that, as that's the most recent version. Alternatively, download the latest version for your system from: http://developer.apple.com/tools/download/ (I think you need to sign up for a free developer account)
Then you can launch shark with a spotlight query. See image 1 for how it should look.
When you experience amule having high CPU load, hit the Start button in Shark and wait till it's finished. You will then get some output similar to image 2 and 3.
I don't know what will be interesting here, so it can be a good idea to save the output from the file menu.
-
eisa01,
Exactly. I knew Mac would not disappoint me. Fancy gui :D
The interesting spots will be the highest peaks, and as I can see by the figure, you can relate the number in the horizontal axis with the name of the routine.
Cheers!
-
hi i have the same problem on a Macbook 2ghz 2gb ram with Leopard. I tryed both amule 2.1.3 and CVS 14 Nov 2007 but the problem still exists. i've done some reports about amule process when it takes all the cpu. i hope these could help to find a solution