Natenoms Wiki

Weil Teilen Spaß macht :)

Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

Übersetzungen dieser Seite:

Navigation



Lizenz dieses Wikis
Über dieses Wiki
Feed des Wikis
Impressum


Was gerade in meinem Blog geschieht:

mumble:tools:mumble-db-tmpfs

Inhaltsverzeichnis

Mumble-Server Datenbank im RAM nutzen (Script)

Mit diesem Script kann man die Datenbank eines Mumble-Servers in den Arbeitsspeicher (RAM) legen, um Datenbankzugriffe zu beschleunigen. Dies ist z. B. notwendig, wenn man Mumble auf einem vServer läuft, auf dem die Festplattenzugriffe teils sehr langsam sind.

Man merkt das z. B. daran, dass es ein paar Sekunden dauert, ehe man den Kanal wechselt, sich stumm stelt oder andere Interaktionen mit dem Server macht.
Normalerweise dauert sowas nichteinmal eine Sekunde.#

Weitere Ansätze zur Lösung dieses Problems gibt es unter „Aktionen wie Verbinden oder den Kanal wechseln in Mumble dauern sehr lange, wenn der Mumble-Server (Murmur) auf einem vServer läuft“.

Idealerweise sollte man auch die Log in dasselbe Verzeichnis legen.

Ist die hier genannte Lösung mit tmpfs auf dem Zielsystem nicht möglich, reicht es vielleicht auch schon aus, beide Logging-Mechanismen des Mumble-Servers zu deaktivieren, siehe unter Logging deaktivieren.

Das Script

Auf einem „alten“ Debian 5 gab es das Problem, dass cp den Parameter -n nicht kennt. Der sorgt nur dafür, dass bereits existierende Dateien nicht erneut überschrieben werden. -n kann weggelassen werden.

Die drei oberen Variablen sind entsprechend anzupassen.

Einen Artikel zum Thema im Blog, siehe hier.

Wenn angepasst, reicht ein „murmur-db.sh mount“ um Murmur zu verwenden und ein „murmur-db.sh unmount“ um die Datenbank vor dem Rechnerneustart wieder abzuspeichern.

Das Script muss als root laufen (auch per sudo möglich).

murmur-db.sh
#!/bin/bash
#This scripts copies your mumble database from a backup directory into a tmpfs and recovers it with unmount.
 
_tmpfs_dir="/home/mumble-server1/database-where-tmpfs-is-mounted/" #This path must be used for database= entry in your murmur.ini
_database_backup_dir="/home/mumble-server1/database_backup_directory/" #This directory must contain the xxx.sqlite before mounting _tmpfs_dir
_owner="murmur" #Name of the user the mumble-server runs as (to set file permissions)
 
case $1 in
  mount)
      if [ "$(mount | grep ${_tmpfs_dir})" != "" ]; then
          echo "Already mounted."
      else
          echo "${_tmpfs_dir} is not mounted. Mounting..."
	  mount tmpfs -t tmpfs "${_tmpfs_dir}"
 
          #if you use debian < 6.x, remove -n
          cp -n ${_database_backup_dir}/murmur.sqlite* ${_tmpfs_dir}/
 
          chown ${_owner}: ${_tmpfs_dir}/murmur.sqlite*
	  echo "Finished :), you can use Mumble now."
      fi
      ;;
  unmount)
      if [ "$(mount | grep ${_tmpfs_dir})" != "" ]; then
	  cp ${_tmpfs_dir}/murmur.sqlite* ${_database_backup_dir}/ 
	  umount "${_tmpfs_dir}"
	  echo "Unmounted."
      else
          echo "${_tmpfs_dir} is not mounted."
      fi
      ;;
  *)
      echo "$0 mount|unmount"
      ;;
esac

Wenn man abschätzen kann, wieviel Speicher die Datenbank in Zukunft maximal verbrauchen wird, so kann man auch mit der Mount-Option „-o 10M“ z. B. 10 MiB des Speichers als tmpfs verwenden. Per Default werden maximal 50% des RAMs verwendet, aber auch erst dann, wenn sie gebraucht werden.

Ursprung dieses Scripts

Ursprünglich entstand dieses Script wegen eines Bugs im Mumble Client der dazu geführt hat, dass eine Verbindung zu einem Server sehr lange dauert (je nach Anzahl der Kanal-Beschreibungen).

Hat man die Datenbank in den Speicher (Ramdisk) geladen, gab es keine Verzögerungen beim Verbinden.

Dieser Bug ist mittlerweile im Git behoben.

mumble/tools/mumble-db-tmpfs.txt · Zuletzt geändert: 2015/11/26 20:21 von Natenom