- Created by Miloš Zeković on 12 05, 2016
Before installing NetVizura make sure to set the time on your server correctly. Time change after the installation will invalidate the license!
Before installing NetVizura you will have to install: Oracle Java 1.7, Tomcat 7 and PostgreSQL 9.3 or higher, in that order. The installation process has been tested on Ubuntu 14.
NetVizura Installation Steps
To install NetVizura follow these steps:
Step 1: sudo package installation: execute apt-get install sudo
Step 2: Oracle Java 1.7 package installation:
Default Java implementation is OpenJDK. You need to install Oracle Java package. Java packages should be installed before the Tomcat7 packages, if not Tomcat will use OpenJDK
in file /etc/apt/sources.list, add the following lines:
deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main
deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main
execute command
apt-get update
ignore the error about "public key is not available"
If you receive something like:
W: GPG error: http://ppa.launchpad.net trusty InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C2518248EEA14886
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/main/source/Sources Hash Sum mismatchW: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/universe/source/Sources Hash Sum mismatch
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/main/binary-amd64/Packages Hash Sum mismatch
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/universe/binary-amd64/Packages Hash Sum mismatch
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/main/binary-i386/Packages Hash Sum mismatch
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/universe/binary-i386/Packages Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead.
enter the following commands:
rm /var/lib/apt/lists/* -vf
apt-get update
3. execute command apt-get install oracle-java7-installer
and answer affirmatively to "Proceed without verification" and all other installation questions
4. execute command ln
-s
/usr/lib/jvm/java-7-oracle
/usr/lib/jvm/default-java
to set Oracle's Java as a default Java on the system
5. check if java is properly installed with command java -version
Step 3: Tomcat 7 package installation:
- execute command
apt-get install tomcat7
- start Tomcat:
service tomcat7 start
- verify that Tomcat is running properly with the command
service tomcat7 status
Step 4: PostgreSQL package installation
Create a file pgdg.list in /etc/apt/sources.list.d/ with some text editor:
nano /etc/apt/sources.list.d/pgdg.list
and add the following line:deb http://apt.postgresql.org/pub/repos/apt/ trusty-pgdg main
execute command:
wget --quiet -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -
execute command
apt-get update
execute command
apt-get install postgresql postgresql-client
verify that PostgreSQL is running properly with the command
service postgresql status
dpkg -i downloaded_file_name.deb
Step 6: Verify installation
Now you can go to NetVizura web interface http://serverip:8080/netvizura. Default login credentials: For example, if your server IP is 1.1.1.1 then point your browser to http://1.1.1.1:8080/netvizura like in the screenshot below:
Post Install Steps
Tomcat Memory Allocation
After installation tweaking of configuration files is required in order to utilize the installed RAM to the fullest extent. The main consumers of RAM are operating system, PostgreSQL database and Tomcat. General rule for distributing memory is to split it in ratio 2:1 between PostgreSQL and Tomcat with 1 GB or more reserved for operating system. For instance:
Installed RAM | PostgreSQL | Tomcat | OS |
---|---|---|---|
4 GB | 2 GB | 1 GB | 1 GB |
16 GB | 10 GB | 5 GB | 1 GB |
During installation NetVizura automatically allocates memory for Tomcat process. The amount allocated to Tomcat process is calculated according to the formula:
(RAMtotal - 1GB) / 3
but no less than 1GB.
For instance:
Total RAM | Tomcat |
---|---|
3 GB | 1 GB |
4 GB | 1 GB |
16 GB | 5 GB |
However, if you need to tweak Tomcat RAM allocation differently (the example for 2048MB):
- Edit file
/etc/default/tomcat7
- Locate
JAVA_OPTS
environment variable that defines memory and uncomment it if it is commented. This line looks something like the following:JAVA_OPTS="${JAVA_OPTS} -Xmx1024m -Xms1024m +UseConcMarkSweepGC"
- Modify the
-Xmx
parameter to allocate additional memory to Tomcat. Additionally, set parameter-Xms
to the same amount. This should look something like:JAVA_OPTS="-Djava.awt.headless=true -Xmx2048M -Xms2048M -XX:+UseConcMarkSweepGC"
- Save the file and restart Tomcat:
service tomcat7 restart
Tweaking PostgreSQL
Tweaking PostgreSQL for best performance is a topic on which many books were written, but the following are some common sense suggestions. In general there are two groups of PostgreSQL tweaks that are helpful for NetVizura performance - "safe" and "unsafe" tweaks. "Safe" tweaks are those which can be applied in all cases. "Unsafe" tweaks trade reliability for performance. For the curious ones recommended reads (among countless others) are PostgreSQL Optimization Guide, PostgreSQL Tuning Guide, this article and this book.
In order to apply following tweaks edit file /etc/postgresql/PG_VERSION_NUMBER/main/postgresql.conf
. You will need to restart the PostgreSQL service after done editing with command: service postgresql restart
. Almost all of the following parameters are commented with carron character (#
). Although these tweaks are considered "safe" do take notice of the default values. Usually you can comment out the parameter that has been changed and PostgreSQL will revert to the default value.
PostgreSQL "safe" tweaks
In the following example it is assumed that 4 GB of RAM is allocated for PostgreSQL.
parameter recommended value comment max_connections
30 NetVizura rarely uses more than 10 connections simultaneously, but it is good to have some reserve shared_buffers
1024MB the recommended amount is RAM/4
effective_cache_size
2048MB the recommended amount is RAM/2
, possibly even RAM * 3/4
chekpoint_segments
32 for write intensive apps (as NetVizura) it should be at least 16, with 32 as safe maximum checkpoint_completion_target
0.9 default_statistics_target
100 work_mem
8MB - 12MB The formula used is max_connections*work_mem <= RAM/8
, but using a bit more is still "safe"
PostgreSQL "unsafe" tweaks
These optimizations are considered "unsafe" since they could in very rare cases lead to data loss and/or corruption. If your VM is properly backed up we would consider the following optimizations safe. The following bring huge performance boosts to DB write process.parameter recommended value comment maitenance_work_mem
32MB speeds up DB self clean process, not really important wal_buffers
16MB full_page_writes
off fsync
off don't wait for HDD to finish previous write operation. This brings the most benefit, but is considered potentially the most unsafe of all. If there is OS or HDD failure in exact instant when PSQL issues write command to HDD, that data will be lost and the DB itself could be corrupted. On the other hand, DB can issue several magnitude more write commands in the same time period and consider all these done, thus improving write performance immensely. synchronous_commit
off similarly to "fsync" but less unsafe and with less benefit checkpoint_segments
64 how much is cached in temp files before it is issued to proper DB files. Issuing big chunks of data for write rarely is usually better for performance than issuing small chunks often
parameter | recommended value | comment |
---|---|---|
max_connections | 30 | NetVizura rarely uses more than 10 connections simultaneously, but it is good to have some reserve |
shared_buffers | 1024MB | the recommended amount is RAM/4 |
effective_cache_size | 2048MB | the recommended amount is |
chekpoint_segments | 32 | for write intensive apps (as NetVizura) it should be at least 16, with 32 as safe maximum |
checkpoint_completion_target | 0.9 | |
default_statistics_target | 100 | |
work_mem | 8MB - 12MB | The formula used is max_connections*work_mem <= RAM/8 , but using a bit more is still "safe" |
parameter | recommended value | comment |
---|---|---|
maitenance_work_mem | 32MB | speeds up DB self clean process, not really important |
wal_buffers | 16MB | |
full_page_writes | off | |
fsync | off | don't wait for HDD to finish previous write operation. This brings the most benefit, but is considered potentially the most unsafe of all. If there is OS or HDD failure in exact instant when PSQL issues write command to HDD, that data will be lost and the DB itself could be corrupted. On the other hand, DB can issue several magnitude more write commands in the same time period and consider all these done, thus improving write performance immensely. |
synchronous_commit | off | similarly to "fsync" but less unsafe and with less benefit |
checkpoint_segments | 64 | how much is cached in temp files before it is issued to proper DB files. Issuing big chunks of data for write rarely is usually better for performance than issuing small chunks often |