- This topic has 7 replies, 3 voices, and was last updated 18 years, 5 months ago by
.
-
Posts
-
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 !
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
Status inquiry
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
top shows:
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 gdbYes that’s 1.27GB VIRT :/
All in all of ~2GB physical mem + swap 8MB is free LOLWould 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.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.
— Ron
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 😉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.
— Ron
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 ?Eddie
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.
— Ron
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.