- 17th November 2005 at 3:41 pm #134
OK, both servers run 20051117 now, let see what happens …17th November 2005 at 8:52 pm #3831
OSX and linux both running for more than 5 hours now, played some music, did some admin stufff …
DOES NOT CRASH (yet) …
Great work Ron !18th November 2005 at 1:58 am #3832saintdevGuest
Well, I eventually got it to hang beating on it with 16 wget loops on the status page overnight. Although I’m not sure it’s not gdb that puked. Here’s what I ended up with from running it overnight:
page: aspl-license.html, uri: /status.html
Got directive session-count
Thread 3381875: Entering ws_dispatcher (Connection from 192.168.0.20)
Thread 3381872: included successfully
Got directive THREADSTAT
Got directive SERVICE-STATUS
Received a message from daap server
Status inquiry — returning 0
Returning status 0
Executing: SELECT COUNT(*) FROM songs
[New Thread 2064079200 (LWP 2978)]
Couldn’t write floating point status: No such process.
^C eventually dropped me back to a gdb prompt, but gdb appears unresponsive
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14854 root 34 19 1307m 447m 600 R 5.7 45.2 164:54.94 gdb
Yes that’s 1.27GB VIRT :/
All in all of ~2GB physical mem + swap 8MB is free LOL
Would that be a leak in mt-daapd or gdb, or not a leak at all?
I’ll try running outside of gdb and see what pops up.18th November 2005 at 7:46 am #3833
Oh, that’s certainly a leak. 🙂
I was more concerned about the crashing though. I’ll find the leak tonight. Maybe I’ll get playcount done, too.
— Ron18th November 2005 at 8:10 am #3834saintdevGuest
I’m not sure that it’s in mt-daapd, though. Had it running for several hours, now, outside of gdb, and VIRT is topping out at 133MB with a low of 79MB. Most of the time it’s at about 90MB. Res is staying steady at about 9MB.
Except for that, no crashes so far 😉18th November 2005 at 1:31 pm #3835
I’ve just been valgrinding it for several hours. I see some small leaks — mostly not freeing on exit type of leaks. The only sustained leaks are those from regexec. Looks like it leaks a fair amount. Hitting it with a several hundred http requests eats up 128k or so of memory.
One solution I saw was to regfree the regexes periodically, to free the retained memory it’s using.
Might have to implement that. Under normal usage, it probably isn’t an issue, and it might be that you would only see it in heavy use (or maybe only ever see it in stress tests), but it’s worth fixing anyway. Probably won’t get to it tonight, though, I’m about done for the night.
— Ron20th November 2005 at 9:22 pm #3836
Running for a couple of days now, no big problems found …
Ron, I noticed the relative slow loading of the playlist … I have some 5500 songs on my xServe and it takes 12 seconds to load the playlist in my Powerbooks iTunes …
I remember you where optimizing some code to improve this, did you drop that to get the rage condition fixed ?
Eddie21st November 2005 at 7:18 am #3837
I took out the stuff that tried to put static playlists back in order that they were inserted into the database, as that was hideously expensive.
I can make it cheaper, but it means I’ll have to special-case how the library is returned versus how the playlists are returned. I really didn’t want to do that. I dunno. I might look at it more.
More importantly that that, though, is that I need to clean up the database code. Now that I know what I need in the database, it might be the case that I can speed some stuff up there.
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.