Desktop and Enterprise Software, Solutions and Services for Chemists and Biologists.

Enterprise Support » FAQ


Question:

My GSLE Server seems to be performing slowly, what steps can I take to remedy this?

 

Answer:

My GSLE Server seems to be performing slowly, what steps can I take to remedy this?

The instructions below detail some ways on how to perform some tuning and optimizations on your GSLE server.

  1. Prerequisites

    An experienced Linux systems administrator is essential, moderate level DBA skills are beneficial to have as well when possible.

  2. System Hardware

    We recommend reviewing the System Requirements Guide to see if your hardware meets minimum requirements. Heavier utilized servers may require more RAM or different hard disk configurations. For example large, very active databases may benefit from a RAID5 configuration, faster disk speeds, or solid state drives. Most servers should be fine with 4GB of RAM and a RAID1 or RAID5 using any disk speeds. Most servers generally do not need more than 2 CPU cores as well. It's usually better to have fewer faster cores, than more slower cores.

    If you have any hardware diagnostic tools you may want to make sure they are running normally. Failing disks, and bad RAM don't always completely fail immediately. Sometimes they will slowly fail, and get worse over time. When this is the case you may notice drastic system performance issues that may or may not be temporarily remedied with a system restart.

  3. Performance tunning and optimizations

    If your hardware is operating normally the next place to look is how your server is configured. There are 2 configuration files to consider, one for Apache and another for Postgres.

    • Tuning Apache: To tune the web server simply open your /usr/local/geospiza/conf/httpd-finch.conf file and ensure that the following minimum recommended directives are added. A full review off all Apache directives is outside the scope of this FAQ, however, there are many online resources to help guide you on tuning Apache for better performance. The following modifications should be more than adequate for normal GSLE use.

      # vim /usr/local/geospiza/conf/httpd-finch.conf
      	MinSpareServers 5
      	MaxSpareServers 15
      	StartServers 10
      	MaxClients 50
      	KeepAlive On
      	MaxKeepAliveRequests 250
      	KeepAliveTimeout 5
      	MaxRequestsPerChild 500
      	

      Note that you must restart Apache for your changes to take effect.

    • Postgres Tuning: Database tuning can require a little more thought that Apache tuning. To help you determine the best settings consider running the pgtune script available here Warning the script can be a bit overzealous in its suggested setting changes, so please consider your modifications carefully.

      In addition to pgtune we have prepared a PG Tuning Guide that will walk you through some of the more common changes. It's a good idea to use this guide in conjunction with pgtune.

      Lastly the setting changes shown below are some minimal changes that we have found work well for most GSLE servers with 4GB+ of RAM.

      # vim /usr/local/geospiza/db/pgdata/postgresql.conf
      	shared_buffers = 256MB
      	temp_buffers = 64MB
      	work_mem = 16MB             
      	maintenance_work_mem = 64MB 
      	effective_cache_size = 512MB
      	stats_start_collector = on
      	stats_row_level = on
      	autovacuum = on
      	

      Note that you must restart Postgres for your changes to take effect.

  4. Routine Database Maintenance

    The GSLE Postgres DB should require little maintenance. This is especially true if you have autovacuum turned on in your postgresql.conf file. Periodic manual vacuuming/analyzing, and reindexing is not a bad idea, especially if you are experiencing performance degradation, or suspect failing hardware.

    • REINDEXING: reindexing your database tables is a common procedure to run against a relational databases. Frequency depends on DB size, use, and complexity. Some DBAs and Sys-Admin's will reindex regularly via cron job. Others will rarely reindex, or only do it when they notice poor database performance. To reindex your GSLE postgres table spaces you will need to run a command like the following. $ cd /usr/local/geospiza/bin; source genv $ sudo -u finch ./reindexdb -a -U -W

      Note that you will need to replace with an actual database super user name. Also note that the command can take anywhere from a few minutes to a few hours to complete, and that your server may become very slow while it is running. Therefore it's a good idea to run it during off hours.

    • VACUUM & ANALYZE: running vacuum with the full + analyze option will ensure the most complete vacuuming of your GSLE DB, and will additionally optimize SQL query run performance. To reindex your GSLE postgres table spaces you will need to run a command like the following. $ cd /usr/local/geospiza/bin; source genv $ sudo -u finch ./vacuumdb -avfz -U -W

      Note that you will need to replace with an actual database super user name. Also note that the command usually takes anywhere from 30 minutes to 5 hours to complete, and that your server will become unusable while the command is running. Therefore it's a good idea to run it during off hours.

  5. Specific Database Actions

    Even with the preventative measures outlined above you may still encounter software performance problems. Reviewing the recent release notes and/or upgrading your software to the most recent version of GSLE is recommended as well before you contact support as your issue may already be resolved and addressed.

    In not, try to look for patterns in the slow down before contacting support. For example, is it a certain page(s), certain action(s), certain times of day? Does the performance issue seem to come and go? Was the problems sudden or gradual?

    The more details support has, the easier pinpointing the cause of the problem will be. In some circumstances we may ask for a copy of your DB to do a full analysis on the structure and review any poorly performing SQL queries given your unique use pattern.




Created on: 3/9/2015
<< Back << Return to support home