These days everybody is moving stuff to the cloud. In many cases there are good reasons to do so. Administering hardware is not what running a modern company is all about in most cases. The key advantage is that virtualization allows people to add and remove servers as needed. However, what does VirtualBox mean to performance?
Some time ago I posted a report on my observations with XEN. As my XEN tests are already a bit outdated I decided to run a small test on VirtualBox to see what happens to performance.
To get a rough estimate of it, I used my local desktop box, which is a 4 core Intel i5-4460 (3.2 GHz). I don't expect too much of a difference on better hardware. VirtualBox was given all CPU cores and 16 GB of memory. However, the amount of data used in the test never exceeds the amount of RAM available, so it is not an issue.
The first thing I did was to compile PostgreSQL to see, what happens to single CPU performance. Here are the results:
| real hardware | VirtualBox | |
| configure | 7.9 sec | 15.5 sec |
| make install | 2 min 31.8 sec | 3 min 0.1 sec |
To me this actually looks pretty good. The loss is somewhat acceptable and actually a bit smaller than expected.
To do a brief test, I created a benchmarking database: pgbench -i -s 10
The output is a small database containing 1 million rows.
The interesting part is that a read-only test shows fairly large differences between “real” iron and my VirtualBox. On real hardware, I got around 77.600 TPS, while VirtualBox failed to exceed 19100 TPS. Interestingly, the tests show that the loss in performance is pretty consistent with what we had a couple of years ago on XEN.
In case you need any assistance, please feel free to contact us.
In order to receive regular updates on important changes in PostgreSQL, subscribe to our newsletter, or follow us on Facebook or LinkedIn.
Occasionally, I uncover long-standing but overlooked PostgreSQL features. One such rarely-used feature is "pg_service.conf," a file you can create to configure services. It simplifies access by eliminating the need to specify host, port, and user details.
How does it work? Well, here's an example:
|
1 2 3 |
iMac:~ hs$ cat .pg_service.conf # a sample service |
[hansservice]
host=localhost port=5432 dbname=test user=hs password=abc
[paulservice]
host=192.168.0.45 port=5432 dbname=xyz user=paul password=cde
In this case two services have been defined. Note that PostgreSQL uses a standard .ini-file format. Inside a section you can use all connection parameters available in PostgreSQL (a full list can be found here: http://www.postgresql.org/docs/9.5/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS).
The first important thing is that a service can be referenced by name. The way to do that is to set an environment variable:
|
1 |
iMac:~ hs$ export PGSERVICE=hansservice |
A connection can now be established without passing parameters to psql:
|
1 2 3 4 5 |
iMac:~ hs$ psql psql (9.5.0) Type 'help' for help. test=# |
Actually a pg_service.conf file is a pretty convenient thing to have. Maybe I should reconsider my behavior, and use this thing more often.
In case you need any assistance, please feel free to contact us.
In order to receive regular updates on important changes in PostgreSQL, subscribe to our newsletter, or follow us on Facebook or LinkedIn.
