- Created by Ognjen Vučetić on 13 05, 2016
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
Version 1 Next »
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 7, Tomcat 7 or higher and PostgreSQL 9.3 or higher, in that order. The installation process has been tested on Windows Server 2008 R2 and Windows Server 2012 R2.
NetVizura Installation Steps
To install NetVizura on Windows follow these steps:
Step 1: Download and install Oracle Java 7 from Oracle official website www.oracle.com/technetwork/java/javase/downloads/index.html
Step 2: Download and install Tomcat 7+ as a service from Tomcat official website tomcat.apache.org. 32-bit/64-bit Windows Service Installer is available on the downloads page
- Make sure to install Tomcat as a service, otherwise NetVizura installation won't be able to complete successfully.
- Make sure you have exactly one version of Tomcat installed on your system, otherwise application might not work as expected.
Step 3: Download and install PostgreSQL 9.3+ from PostgreSQL official website http://www.postgresql.org/download/windows/
- While PostgreSQL installation you will be prompted for username and password, make sure that username is "postgres" and password is "postgres".
- Make sure you have exactly one version of PostgreSQL installed on your system, otherwise application might not work as expected.
Step 4: Download NetVizura Windows Installer from NetVizura website and run installer with administrative privileges
Step 5: Follow the installation steps
Step 6: Verify installation
Error rendering macro 'excerpt-include'
No link could be created for 'Linux CentOS (ISO) Installation'.
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):
- Double click on Apache Tomcat Properties in system tray
- In Java tab under Java options modify the
-Xmx
parameter to allocate additional memory to Tomcat. Additionally, set parameter-Xms
to the same amount. Also set Initial memory pool and Maximum memory pool to the same amount. This should look like on picture below. - Back to the General tab, click Stop and Start to restart Tomcat.
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 postgresql.conf
, this file is usually located in PostgreSQL data folder. You will need to restart the PostgreSQL service after done editing. 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.
In the following example it is assumed that 4 GB of RAM is allocated for PostgreSQL. Before changing any parameters in postgresql configuration read the provided comments in the table below for more information regarding specific parameter. The recommended amount is The formula used is Increasing 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 RAM/2
, possibly even RAM * 3/4.
checkpoint_completion_target
0.7 This parameter can take values between 0 and 1. Default is set to 0.5, which means that the write phase of checkpoint process will take half of the checkpoint timeout time. Increasing this value will provide more time for checkpoint write phase to finish, thus decreasing IO usage. work_mem
32-64MB max_connections*work_mem <= RAM/4
, but using a bit more is still fine.maintenance_work_mem
256MB Speeds up DB self clean process. Usually 4*work_mem or something in that ballpark wal_buffers
16MB wal_buffers
is helpful for write-heavy systems. Usually this is 16MB.min_wal_size
1GB If WAL files are under this size, files will be recycled for future checkpoints. max_wal_size
2GB Maximum size of WAL files, after that CHECKPOINT command is be issued and files are written to disk. effective_io_concurrency
2 Number of simultaneous request that can be handled efficiently by disk subsystem. full_page_writes
off Turning this parameter off speeds up normal operation, but might lead to either unrecoverable data corruption, or silent data corruption, after power outage, OS or HDD failure. The risks are similar to turning off fsync
, though smaller.fsync
off Don't wait for HDD to finish previous write operation. This brings the most benefit, but if there is power outage, 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 with less benefit. Parallel system optimization (PSQL => 9.6) max_worker_processes
2 Number of cores max_parallel_workers_per_gather
1 Number of cores/2 (PSQL > 9.6) max_paralllel_workers
2 Number of cores
- No labels