Category Archives: Performance

Clean up and compact your VDI

Tweet about this on TwitterShare on Google+Share on RedditShare on LinkedInShare on FacebookBuffer this page

TL;DR

Guest OS: sudo sfill -llvz /

Host OS: VBoxManage modifyhd --compact <_.vdi>

Details

My VirtualBox thin server had put on a few pounds over the months of guest OS database imports, static resource creation, temp file creation, log rotation, and a bunch of other stuff I don't need to store indefinitely. Every time more sectors need to be called upon to store something in the guest, VirtualBox will grow the physical VDI image accordingly, up to the maximum size specified. However, when you delete files from the guest system, the VDI doesn't shrink accordingly (and with good reason).

If you have implemented a backup strategy — as I have with Time Machine — you probably don't want to back up a 30 GB VDI file every single time a single bit changes (for example, when you boot the virtual machine). This is particularly true when you have deleted old databases, resources and logs, and the guest OS really only represents about 5 GB of data.

VBoxManage modifyhd allows you to compact a physical VDI, but with one important precondition, it only truncates zeros in the guest from the VDI:

With the --compact option, can be used to compact disk images, i.e. remove blocks that only contains zeros. This will shrink a dynamically allocated image again; it will reduce the physical size of the image without affecting the logical size of the virtual disk. Compaction works both for base images and for diff images created as part of a snapshot.

So simply having deleted a file from your guest will not allow you to reclaim space. You have to zerofill the free space on guest OS's volumes.

In your Guest (in this case, Ubuntu Server 12.04.02 LTS)

sudo apt-get install secure-delete
sudo sfill -llvz /

The -ll option writes only one pass (instead of the default 38) and the -z option replaces the single pass of data from /dev/urandom with zeros, which is what VBoxManage is looking for.

In your host:

VBoxManage modifyhd --compact <virtual_disk_file.vdi>

I shrunk mine from 25 GB to 5 GB in a single step. My SSD allowed me to zerofill about 20 GB in the guest and compact the VDI in less than 90 seconds.

Manpages

 

Using subverison 1.7 with phpStorm, webStorm or IntelliJ IDEA on Mac OS X

Tweet about this on TwitterShare on Google+Share on RedditShare on LinkedInShare on FacebookBuffer this page

I use the JetBrains' phpStorm 6 IDE at work. It currently supports VCS integration with local subversion 1.6 and 1.7 repositories. According to JetBrains, using the subversion 1.7 command-line client is significantly faster at calculating file changes for big projects than using the svnkit library (which is the in-built tool phpStorm will otherwise use).

TL;DR

Instacod.es version of the code below

Best performance

For best performance, you should employ an svn 1.7 repository and specify a command-line client binary. The problem is, OS X 10.8's latest XCode (4.6.3) Comman Lline Tools installs subversion 1.6.18, and Homebrew and Fink were updated to subversion 1.8 by default, which phpStorm does not currently handle.

Trying to browse a version 1.7 repository with a version 1.8 client binary within the IDE will simply not work.

Homebrew to the rescue

First, if you're a developer of any kind, are running OS X but you're not using Homebrew (GitHub repo): you're missing out!

Using Homebrew, tap the older svn 1.7 and install it:

$ brew tap homebrew/versions
$ brew install subversion17

(make took a really long time to build subversion, for some reason. If you don't like to stare at a blank terminal and wonder, add the --verbose flag to brew install.)

Then, specify brew's command-line svn binary (/usr/local/bin/svn) in phpStorm, webStorm or IntelliJ IDEA:

Using brew's svn client at /usr/local/bin/svn

Compiling xslcache 0.7.1 for PHP 5.4

Tweet about this on TwitterShare on Google+Share on RedditShare on LinkedInShare on FacebookBuffer this page

We make heavy use of xslt at work (parsing xml data generated by php controllers), so the xslcache pecl module is pretty fundamental to our infrastructure. Of course, if you are using PHP 5.4 or above, like many pecl modules, it breaks. Here's how to get it to work.

Currently, trying sudo pecl install xslcache-beta with PHP >= 5.4 throws the following error at make:

/tmp/pear/temp/xslcache/php_xsl.c: In function 'xslcache_objects_new':
/tmp/pear/temp/xslcache/php_xsl.c:211:52: error: 'zend_class_entry' has no member named 'default_properties'
make: *** [php_xsl.lo] Error 1
ERROR: `make' failed

Download xslcache

Download the original source from the pecl svn repository, the 5.4 patch, and patch it manually:

svn checkout http://svn.php.net/repository/pecl/xslcache/trunk xslcache
cd xslcache
wget -O php_xsl.c.patch 'https://bugs.php.net/patch-display.php?bug_id=62856&patch=xslcache-php5.4-compat&revision=1362641549&download=1'
patch < php_xsl.c.patch

Make and install

This is a pretty straightforward make process for most linux software (you may need to adjust the location of xslcache.ini):

phpize
./configure
make
make test
sudo make install
sudo nano /etc/php5/cgi/conf.d/xslcache.ini
#add "extension=xslcache.so"

Note that if you make test the tenth may fail with the following:

=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
Test 10: EXSLT Support [tests/xslt010.phpt]
=====================================================================

If you're using XSLT 2.0, you probably don't need to worry about it.

Verify that xslcache is installed and enabled

Since we're already in the command line, let's check there:

php -i | grep XSLCACHE

Hopefully, you will see the following line:
XSLCACHE => enabled
Furthermore, you should be able to actually know it's doing its job because your benchmarks should improve.