This page describes KOTETU 1.3 and later installation over Linux 2.2.x .


Object Cache Files Setup

You should do object cache file setup to archive better performance. You can run the program without these procedures, however the performance of that situation will be bad. See end of this document about performance without this setup procedure.

Summary (and Overview)

Makefile configuration file operation
Single-disk -DOFILE_SLOT=1027 -DOFILE_BLOCK=8192 NumBucket 509 RadixH2 3 CacheDir /cache % mkdir /cache % mount /dev/sdb0 /cache % ./mkpack 1027 2128 8192 % ./cppack /cache 509 3

Multi-disks -DOFILE_SLOT=1027 -DOFILE_BLOCK=8192 NumBucket 509 RadixH2 3 CacheDir /cache@4 % mkdir /cache0 /cache1 /cache2 /cache3 % mount /dev/sda1 /cache0 % mount /dev/sdb1 /cache1 % mount /dev/sdc1 /cache2 % mount /dev/sdd1 /cache3 % ./mkpack 1027 2128 8192 % ./cppack /cache@4 509 3

Bind Name

Kotetu accesses many files via filesystem. Kotetu requires specification of directory for WWW cache. Edit configuration file as your site.

CacheDir /cache

Cache Capacity

In besically, cache capacity is solved OFILE_SLOT x (OFILE_BLOCK + sizeof(skcache_entry_t)) x BucketNumber x RadixH2 . In addition, real filesystem needs more area for superblock, directory and some reason (aligements, fragmentation and others).

When compiling, OFILE_SLOT, OFILE_BLOCK and sizeof(skcache_entry_t) are decided. If you want to change these parameters, you have to compile the program. OFILE_SLOT and OFILE_BLOCK is described in Makefile. skecache_entry_t is defined in xsk.h . range.h will helps your tunning.

BucketNumber and RadixH2 are specified by configuration file. If you change these parameters, you have to run 'cppack' (it is shown below).

Example:

OFILE_SLOT OFILE_BLOCK *entrysize BucketNumber RadixH2 total
1027 12K (12288B) 208 509 3 18.25G
1027 12K (12288B) 2128 509 3 21.05G
1027 12K (12288B) 2128 223 7 21.52G
1027 12K (12288B) 2128 509 11 77.20G
*entrysize: sizeof(skcache_entry_t)

Cache Initialization

Since Kotetu 1.2 handles several thousands files, file overhead (creation and seeking) is occured. In addtionaly, its random access makes block holed file. By disk initialization before running, the overhead can improved.

  1. make index and packed object files.

    Kotetu use 2 file. First, INDEX consists control blocks for cache object. In default, it is 2128 bytes per object (which means sizeof(skcache_entry_t)). Second, BODY consists data blocks for cache object. In default, it is 12288 bytes (which is defined xsk.h or Makefile). mkpack make INDEX and BODY with specified parameters.

    % ./mkpack 1027 2128 8192

    However, 2128 is long. You should change length as tunning.

  2. copy these file to cache area

    copy INDEX and BODY to all directories over filesystems. 509 and 3 mean first and second hash (NumBucket and RadixH2).

    % ./cppack /cache 509 3

I/O Separation

Since a mix of disk access for WWW caching and others causes latency, Kotetu recommends using disk(s) which is separated from other I/Os (but it is not required). Add yet another disk contoller for WWW caching, if possible.

Multipul Disks

Performance of Kotetu depends disk I/O. Especially, most filesystems are very slow than the bare speed of disks. You should use multipul disks to archive better performance. In addition, multipul partitions over single disk will cause interesting effects. You have to set 'CacheDir' in configuration file as using multipul prefix. For example, if you want to use 2 partitions, you have to name them as '/cache0' and '/cache1', and edit configuration file as following line:

CacheDir /cache@2

The letter '@' means using multiple prefix. '2' means two partitions.

If your disk controller has logical disk feature, your system will brings more performance by that. In this case, you shoulde configure according to above example, also.

Filesystem Type and newfs

To archive better performance, you shoulde use a faster filesystem and turn them. Of couse, filesystem initialization (newfs) is recommended before run the program, because the fragmentation of file system cause overhead.

We use ReiserFS for cache areas with options-"noatime,nolog,notail" .


What Happen, without these procedures ?

Since Kotetu 1.2 accesses variaus files in random. Random access cause overhead (creation and seeking). In addtionaly, its random access makes block holed file. Then, your system does not acrchive better performance without procedures in above.