Disabling Indexing On the Synology DS216+

After 6 years, I finally upgraded my Synology DS209 to a DS216j, and still find indexing to be a problem service that I want to turn off. A few things I found out about how the indexing service is setup on the newer DS216j:

1) Finding the running index processes:
ps ax|grep index
6291 ? SNs 0:00 /usr/syno/sbin/synoindexd
6788 ? SN 0:00 /usr/syno/sbin/synoindexscand
6789 ? SN 0:00 /usr/syno/sbin/synoindexworkerd
6790 ? SN 0:00 /usr/syno/sbin/synoindexplugind
22715 pts/3 S+ 0:00 grep –color=auto index

2) Indexing is controlled through an Upstart job located at /usr/syno/sbin/synoindexd
You can review all Upstart jobs by issuing the command “initctl list”

3) If you want to look at the index job specifically, issue the “initctl show-config synoindexd” command to reveal the specifics of the job:

start on started pgsql-adapter
stop on stopping pgsql-adapter

4) If you want to review the script itself, open the /etc/init/synoindexd.conf file:

description “configure network device”
author “Web Application Team”

start on started pgsql-adapter
stop on stopping pgsql-adapter

expect fork

respawn limit 5 10

pre-start script

# make sure pgsql is running
if /usr/syno/sbin/synoservice –is-enabled pgsql > /dev/null 2>&1; then
echo “PGSQL service is disabled. Skip…”
exit 1

end script

exec /usr/syno/sbin/synoindexd

post-stop script
echo “Stopping Synology Index Daemon…”
killall synoindexscand > /dev/null 2>&1 || true
killall synoindexworkerd > /dev/null 2>&1 || true
killall synoindexplugind > /dev/null 2>&1 || true
killall synomediaparserd > /dev/null 2>&1 || true
end script


Notice that the index script is tied to the Postgresql database start. If you try killing the index service with a “kill -9” command it will kill the process, and then restart it. I have not yet tried, but perhaps the best way to stop the index service is to edit the /etc/init/synoindexd.conf file and change the “start on started pgsql-adapter” line to “stop on started pgsql-adapter.”

I will update this post as I try this solution.


Tuning your Synology NAS for speed

If you own a Synology NAS device at home, you know its an incredible machine for the money. However, it likely has a small amount of RAM (mine has 256MB) and that poses a problem. I have found that if you are not using many of the programs (Disk Station, iTunes server, File Station, etc…), you can free up a great deal of RAM by disabling unused services. This gives precious RAM back to processes that can actually use it, and frees up CPU power.

The first step is to disable services you do not need. For me, this includes all the file indexing and thumbnail services, CUPS printing, USB hotplug, and a few other miscellaneous services. Ensure that SSH access is on (Control Panel – Terminal – Enable SSH Service) and login to the device via SSH.  Then issue the following commands:

/usr/syno/etc/rc.d/S56synoindexd.sh stop
/usr/syno/etc/rc.d/S88synomkflvd.sh stop
/usr/syno/etc/rc.d/S77synomkthumbd.sh stop
/usr/syno/etc/rc.d/S55cupsd.sh stop
/usr/syno/etc/rc.d/S20pgsql.sh stop
/usr/syno/etc/rc.d/S66fileindexd.sh stop
/usr/syno/etc/rc.d/S03hotplugd.sh stop
/usr/syno/etc/rc.d/S03inetd.sh stop
/usr/syno/etc/rc.d/S98findhostd.sh stop

These commands will stop the services from running, but they will restart at the next reboot. To prevent this, simply change the executable status of each service’s start script to be un-executable. This will ensure that disabling these services survives the next reboot. Issue the following commands:

chmod -x /usr/syno/etc/rc.d/S66synoindexd.sh
chmod -x /usr/syno/etc/rc.d/S88synomkflvd.sh
chmod -x /usr/syno/etc/rc.d/S77synomkthumbd.sh
chmod -x /usr/syno/etc/rc.d/S55cupsd.sh
chmod -x /usr/syno/etc/rc.d/S20pgsql.sh
chmod -x /usr/syno/etc/rc.d/S66fileindexd.sh
chmod -x /usr/syno/etc/rc.d/S03hotplugd.sh
chmod -x /usr/syno/etc/rc.d/S03inetd.sh
chmod -x /usr/syno/etc/rc.d/S98findhostd.sh

Note that some of these services might be needed by services you want to run on your DiskStation. You may cherry-pick the services you wish to disable. I only use my DiskStation as a local backup target and have it push to Crashplan, so my requirements are very low. You can reenable a service by using the reverse “chmod +x” command and restarting it.

Next, open the /etc/sysctl.conf file, and add the following network-related settings:

net.ipv4.tcp_rmem= 10240 87380 12582912
net.ipv4.tcp_wmem= 10240 87380 12582912
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1

This will provide a number of TCP tunings for the Gigabit ethernet card that the DiskStation uses. After making all of these changes, be certain to reboot the box to clear system RAM and caches. You should find that your DiskStation is now more responsive, and tasks should execute much faster.


Good quotes from Oracle "Unlimited Application Scalability" whitepaper

The cost of each tier in a web application increases as you move from URL to SQL. From the white paper:

“In the first tier—the Web tier—the cost of serving static content by use of commodity boxes running Apache is very low and, due to its stateless nature, very predictable.

• In the second tier—the J2EE tier—the cost of hardware may be the same, but both the infrastructure software and the custom application logic are significantly more expensive.

The result is predictable: Applications that tend to allow each request to get past the first or second tier will be much more expensive to scale, and applications that rely on data access from the database for each request will encounter severe limits on their scalable performance.

The lesson learned is this: handle the incoming load in the earliest-possible tier, and do it with resources that have predictable scale-out behavior and costs. For most applications, those are the resources represented by commodity hardware—servers with fast CPUs and plenty of memory.

Also, you should deliberately build an architecture that will bottleneck in the earliest-possible tier on either the CPU or in memory. Why? You’re going to have a bottleneck, whether you choose to or not. And if you don’t pick the bottleneck deliberately, it’s going to end up in the most expensive and difficult-to-scale part of your environment.”

Great quote about caching…

“When building a big web application you layer caches on caches. Ideally the top cache (browser local cache) can service the entire request such as it happens on google.com. if that fails the next best thing is blazingly fast memcached. Failing that we have to aquire and compute some data which is hopefully cached. If that fails the database gets the data from its cache or from disk. If that fails than the database files are probably cached by the operating system. And finally we move the physical read head of the disk to fetch the database off permanent storage.”


I found this excellent listing of Cache-Control definitions on askapache.com:

Cache-Control: no-store
This object may not be stored in any cache, even the requestor’s browser cache.

Cache-Control: no-cache
This object may be held in any cache but it must be revalidated every time it is requested.

Cache-Control: private
This object can be stored in the requesting browser´s cache but not in a shared cache …

Cache-Control: must-revalidate
Tells caches that they must obey any freshness information you give them about an object. The HTTP allows caches to take liberties with the freshness of objects; by specifying this header, you’re telling the cache that you want it to strictly follow your rules.

Cache-Control: proxy-revalidate
Similar to must-revalidate, except that it only applies to proxy caches.

Using web server logs to ensure browser caching is working

The first time a browser requests a file, an HTTP code of 200 (request for document) will be written to the web server log. It will look like this: – – [21/Oct/2006:14:38:23 -0700] “GET /OA_MEDIA/FNDREDPT.gif HTTP/1.1” 200 70

The next time the request is received from the browser, it should be served by the browser cache. Thus the entry in the web server log file will be an HTTP code 304 (request for time stamp). It will look like this: – – [21/Oct/2006:14:41:03 -0700] “GET /OA_MEDIA/appslogo.gif HTTP/1.1” 304

Speed up your browsing with dd-wrt

Have you changed the firmware on your Linksys router to dd-wrt? If you did, you can make a simple configuration change to the dnsmasq service that provides DNS and DHCP services. Login to the router, and browse to the Administration/Services tab, and add the following entry:

This tells the DNSMasq service to cache 2000 DNS entries. The result is that any DNS request (one is made for EVERY website request) will be served up by the local Linksys router, rather than obtaining the request from a DNS server on the Internet.

By caching DNS requests locally, you will see faster browser response times. While this DNS lookup time savings may only be milliseconds, for sites you visit multiple times in a session you will see a large boost in performance. Such sites will feel more responsive.

Here is an example of a Linux server (also behind the Linksys router) performing “dig” lookup against Google:

# dig www.google.com | grep “Query time”
Query time: 16 msec

# dig www.google.com | grep “Query time”
Query time: 1 msec

For the first request, google.com’s details were not in the Linksys cache, and the query took 16ms. The second time, the cache speeds up the lookup, and the time is reduced to 1ms.

If you login via SSH to the Linksys router and send a sigusr1 to the DNSMasq service, you can obtain a listing of the entries it is caching:
# killall -sigusr1 dnsmasq
dnsmasq: time 259374, cache size 2000, 0/16 cache insertions re-used unexpired cache entries.
dnsmasq: Host Address Flags Expires
dnsmasq: del.icio.us 4F 31
dnsmasq: www.boingboing.net 4F 281
dnsmasq: bloglines.com 4F 4294967282
dnsmasq: WRT54G 4FRI H 0
dnsmasq: pageflakes.com 4F 501127
dnsmasq: www.bloglines.com bloglines.com CF 633
dnsmasq: feeds.feedburner.com 4F 42

Loadrunner and the rstat daemon

Loadrunner (and other monitoring tools) needs the rstat daemon to extract data from the kernel. Installing this daemon is a bit tricky, as it is part of a larger package. Here’s how you do it:

# up2date -i rusers-server

To start the daemon: # service rstatd start

NOTE: Ensure the portmap service is running first.

NMI (Non-Maskable Interrupt)

A server is always executing interrupts; giving attention to whatever needs it. These are so-called maskable interrupts. The CPU can mask, or temporarily ignore, any interrupt if it needs to in order to finish something else that it is doing. There are also non-maskable interrupts (NMI), which are used for serious conditions that demand the processor’s immediate attention.

When an NMI signal is received, the processor immediately drops whatever it was doing and attends to it. The NMI cannot be ignored by the server. The NMI signal is normally used for critical problem situations, such as serious hardware errors. The most common use of NMI is to signal a parity error from the memory subsystem.