Murmur going molasses and questionable connection

[captain_rage]

I've ran into utterly strange problems when installing and setting up Murmur.

It started when I decided to try to install Murmur on my Raspberry Pi (which is only running lighttd, under a fresh install of Arm Arch Linux). This server is only used to serve a single page for a couple of users on a local area network, so it is never under really heavy load. The same machine is assigned a local IP address by a Linksys router that's running dd-wrt.

After the installation I enabled Murmur under systemd by running:

sudo systemctl enable murmur.service

 

Now the foobar-ness begins.... It is possible to connect to the machine, using its local IP address, but it is really, REALLY, unresponsive. Before connecting it shows a latency of a 17 digit (!) delay in ms (remember, it is on the LAN, and thus the ping should be "non-existent"). When changing chat rooms it behaves really unresponsive, as well as when connecting (both takes very long time).

The server also gives away this dubious message:

[10:36:33] UDP packets cannot be sent to or received from the server. Switching to TCP mode.
[10:36:54] UDP packets can be sent to and received from the server. Switching back to UDP mode.

 

http://i.imgur.com/rHP34uB.png

http://i.imgur.com/uRdNBCK.png

Before connecting was possible I had to edit /etc/murmur.ini and change

#host=

to

host=192.168.1.105

Other than that, I haven't poked around too much in murmur.ini.

The only reference I have found to this problem is http://sourceforge.net/p/mumble/discussion/492607/thread/dd5408be, even if it didn't help me a single bit.

Herp, derp... Help..? What is causing this madness?!

[hacst]

Not really sure what's up with that UDP ping. The sluggishness on move can be caused by high iowait. You could try moving your murmur.sqlite database into a tmpfs and see if that speeds things up.

[ngollan]

Repeat after me, "The Raspberry is most definitely not a realtime system."

Good.

The initial delay you're seeing is most from the Rpi's storage sucking some major behind for databases, so you may want to put the DB file on a tmpfs (and of course care for properly persisting it before shutdown).

It might help if you just disable database logging, since that removes quite a few blocking write operations, but you will likely still see some delays on logging in and switching channels.

[captain_rage]

Gentlemen... You are both very ingenious and your expertise proved more than useful.

Indeed, it was the poor SD card on the Raspberry Pi that was causing the drama.

After installing anything-sync-daemon (a program to do exactly what ngollan suggested) the Murmur server suddenly became extremely responsive. No problem whatsoever to have a couple of people to join and talk, let alone letting a single user to connect.

The only information I could find regarding running Murmur on the Raspberry Pi said that it would "work fine". I couldn't possibly imagine that Murmur was writing/reading from the database file so intensively, and that would bork things up, because the system monitor wasn't reporting a heavy load at all.

So, today's lesson learnt: CPU usage doesn't say much about I/O to the drive.

The only mystery that remains is why the ping is showing those insane numbers before connecting through the local network to the server. Once connected (after applying the fixes) the ping in the Control Channel is minimal, though, and the functionality is where it should be.

To sum it up: a Raspberry Pi can actually be a nice Murmur server - as long as you set it up to avoid its worst bottlenecks.

Thanks for the hints, both of you. It is greatly appreciated. This matter is now solved. :)

@ngollan: "+1". Amen.

However, I got a few more questions..

Why so many read/writes to the database, constantly...? Murmur gave the impression that the machine choking, even when it was idling, and other processes were running fine. Are images, channels, registred users, etc, all stored in that single database file?

Why are there three instances of Murmur running? Is it normal?

http://i.imgur.com/z2pCnJG.png

[hacst]

Everything you mentioned is stored in the database. Basically every bit of persistent state. Including the log entries unless you disabled that. Each database write triggers a flush to disc (no buffering) and if the io system is as horrible as a slow SD card that might take a considerable while for each and every one.

The processes you see are a father with a few threads. Under Linux those get their own process identifier which looks a bit confusing in tools that don't hide those. Take a look at the output from pstree -apun to see the nesting.

[captain_rage]

Thank you very much for clarifying and elaborating these aspects. :D It all makes sense now.

Still learning these things..

Cheers!