Mauro Morales

software developer

Month: April 2016

  • Running Multiple Redis Instances

    This article will teach you how to run one or more Redis instances on a Linux server using systemd to spawn copies of a service.


    The easiest way to install Redis in Linux is with your distributions package manager. Here is how you would do it on openSUSE:

    sudo zypper install redis

    In case your distribution doesn’t provide a Redis package, you can always follow the upstream instructions to compile it from scratch.


    1. Make a copy of the example/default file that is provided by the packagecd /etc/redis/ cp default.conf.example my_app.conf Use a name that will help you recognize the purpose of the instance. For example if each instance will be mapped to a different application give it the name of the application. If each instance will be mapped to the same application use the port in which it will be running.
    2. Change the ownership of the newly created configuration file to user “root” and group “redis”chown root.redis my_app.conf
    3. ConfigurationAdd a “pidfile”, a “logfile” and a “dir” to the .conf file.pidfile /var/run/redis/ logfile /var/log/redis/my_app.log dir /var/lib/redis/my_app/ Each of these attributes has to match with the name of the configuration file without the extension.Make sure the “daemonize” option is set to “no” (this is the default value). If you set this option to yes Redis and systemd will interfere with each other when spawning the processes.daemonize no Define a “port” number and remember that each instance should be running on a different port.port 6379
    4. Create the database directory at the location given in the configuration fileinstall -d -o redis -g redis -m 0750 /var/lib/redis/my_app The database directory has to be owned by user “redis” and group “redis” and with permissions 750.

    Repeat these steps for every instance you want to set up. In my case I set up a second instance called “my_other_app”

    ├── default.conf.example
    ├── my_app.conf
    └── my_other_app.conf


    In order for systemd to know how to enable and start each instance individually you will need to add a service unit inside the system configuration directory located at /etc/systemd/system. For convenience you might also want to start/stop all instances at once. For that you will need to add a target unit.

    In case you installed Redis on openSUSE these two files will be already provided for you under the system unit directory /usr/lib/systemd/system.

    1. Create the service unit file “redis@.service” with the following contents:[Unit] Description=Redis[Service] Type=simple User=redis Group=redis PrivateTmp=true PIDFile=/var/run/redis/ ExecStart=/usr/sbin/redis-server /etc/redis/%i.conf Restart=on-failure[Install] The unit file is separated in sections. Each section consists of variables and the value assigned to them. In this example:
      • After: when the Redis instance is enabled it will get started only after the network has been started.
      • PartOf: this instance belongs to the and will get started/stopped as part of that group.
      • Type: simple means the service process doesn’t fork.
      • %i: a specifier that is expanded by systemd to the “my_app” instance.
    2. Create the target unit file “” with the following contents:[Unit] Description=Redis target allowing to start/stop all redis@.service instances at once


    If everything went as expected you should be able to interact with the individual instances:

    systemctl start redis@my_app
    systemctl enable redis@my_other_app

    And also with all the instances at the same time:

    systemctl restart
    systemctl stop


    If things didn’t go as expected and you cannot start the instance make sure to check the instance’s status:

    systemctl status redis@my_app

    If the issue doesn’t show up there then check systemd’s journal:

    journalctl -u redis@my_app

    For example if you forgot to give the right permissions to the configuration file you’d see something like this inside the journal:

    Apr 23 10:02:53 mxps redis-server[26966]: 26966:C 23 Apr 10:02:53.917
    # Fatal error, can’t open config file ‘/etc/redis/my_app.conf’


    • Thanks to the openSUSE Redis package maintainers for creating such a nice package that you can learn from it.
    • The book How Linux Works provided the details on how systemd instances work.
  • Profiling Vim

    I like Vim because it’s very fast. Unfortunately the other day I found myself opening a diff file that took forever to load. The file had 58187 (this number will be important later on) lines in it but I never thought Vim would choke with something that was less than 2M size.

    This post was originally published on medium


    If you find yourself in a similar situation this is what you can do in order to find out what is causing Vim to slow down.

    1. Open Vim and start profiling:profile start /tmp/profile.log :profile func * :profile file * This is telling Vim to save the results of the profile into/tmp/profile.log and to run the profile for every file and function.Note: The profile.log file only gets generated until you close Vim.
    2. Do the action that is taking a long time to run (in my case opening the diff file):edit /tmp/file.diff :profile pause :q!
    3. Analyze the dataThere is a lot of information in /tmp/profile.log but you can start by focusing on the Total time. In my case there was a clear offender with a total time of more than 14 seconds! And it looked like this:FUNCTION <SNR>24_PreviewColorInLine() Called 58187 times Total time: 14.430544 Self time: 2.961442 Remember the number of lines in the file I mentioned before? For me it was interesting to see that the function gets called just as many times.
    4. Pinpoint the offenderFinding out where a function is defined is very easy thanks to the <SNR> tag and the number right after it. You simply need to run :scriptnames and scroll until you find the index number you are looking for, in my case 24.24: ~/.vim/bundle/colorizer/autoload/colorizer.vim

    I opened up a GitHub issue to make the developers of the plugin aware but it seems as if the project has been left unmaintained so I decided to remove it from my vimrc file.