Skip to main content


Showing posts from January, 2012

Page cache perils

I am sharing my experience with benchmarking the Voldemort Server- effectively a Java key-value storage server application on Linux (referred as 'server' from here on). The application handles put(k,v) and get(k), like a standard HashMap, only difference being these are calls over the network, and the entries need to be persistent.What the post talks about is generic and could apply to most java server applications. The goal here was to run a workload against the server, in a manner that it comes off disk, so we exercise the worst case path. As easy as it may sound, certain things come in our way OS Page Cache - Linux caches files the server writes/reads (unless you do direct I/O and build your own cache on top of it) JVM memory management - the JVM heap shares the same physical memory as the page cache and you don't have very fine control over how much memory it will take.  This interplay is tricky as we will see below, in terms of actually controlling the page

Java file.canWrite always returning true

This is going to be very short. Actually does not entail a blog post. Anyways, here goes. So, when I was trying to setup some Junit tests on an EC2 instance, I stumble into this ridiculous failure where, file.canWrite() simply returns true, no matter what. A code like below, keeps printing the "file is writable" import; public class Test1 {         public static void main(String[] args) throws Exception {                 File file = new File("hello.txt");                 file.createNewFile();                 file.setReadOnly();                 if (file.canWrite()) {                         System.out.println("File is writable!");                 } else {                         System.out.println("File is in read only mode!");                 }         } } Turns out, the culprit is that I am running as "root". Since root can do-it-all, it simply returns true even though the file permissions read [root@myhos