Archive
Posts from 2007
Preallocating files sequentially on VxFS file systems
One cool feature that is built into VxFS is the ability to preallocate files sequentially on disk. This capability can benefit sequential workloads, and will typically result in higher throughput since disk seek times are minimized (LBA addressing, disk drive defect management and storage array abstractions can sometimes obscure this, so this may not always be 100% accurate). To use the VxFS preallocation features, a file first needs to be created: In this example, I created a 1GB file (2097152 blocks 512-bytes per block gives us 1GB) named oradata01.dbf, and double checked that it was 1GB by running ls with the "-h" option: total 3.1G -rw-r--r-- 1 root root 1.0G Aug 25 09:06 oradata01.dbf After a file of the correct size has been allocated, the setext utility can be used to reserve blocks for that file, and to create an extent that matches the number of blocks allocated to the file: To verify the settings that were assigned to the file, the getext utility can be used: oradata01.dbf: Bsize 1024 Reserve 2097152 Extent Size 2097152 This is an awesome feature, and yet another reason why VxFS is one of the best file systems available today!
$ read more →Backing up the Veritas Cluster Server configuration
Veritas cluster server stores custom agents and it's configuration data as a series of files in /etc, /etc/VRTSvcs/conf/config and /opt/VRTSvcs/bin/ directories. Since these files are the life blood of the cluster engine, it is important to backup these files to ensure cluster recovery should disaster hit. VCS comes with the hasnap utility to simplify cluster configuration backups, and when run with the "-backup," "-n," "-f ," and "-m cluster configuration will be written to the file passed to the "-f" option: To check the contents of the snapshot, the unzip utility can be run with the "-t" option: Since parts of the cluster configuration ran reside in memory and not on disk, it is a good idea to run "haconf -dump -makero" prior to running hasnap. This will ensure that the current configuration is being backed up, and will allow hasnap "-restore" to restore the correct configuration if disaster hits.
$ read more →Watching slab usage with slabtop
The Linux kernel uses a slab based allocator to allocate kernel memory. Inside each slab is a collection of objects that have been allocated by one or more kernel subsystems. To monitor slab utilization in realtime, most modern day Linux distributions ship with the slaptop utility. When slabtop is run without any arguments, it displays a nice slab usage summary, and provides details of how various slabs are being used: These is a sweet utility, and is another one of those tools that should be in every Linux administrators tool belt.
$ read more →Using the Solaris coreadm utility to control core file generation
Solaris has shipped with the coreadm utiltiy for quite some time, and this nifty little utility allows you to control every facet of core file generation. This includes the ability to control where core files are written, the name of core files, which portions of the processes address space will be written to the core file, and my favorite option, whether or not to generate a syslog entry indicating that a core file was generated. To begin using coreadm, you will first need to run it wit the "-g" option to specify where core files should be stored, and the pattern that should be used when creating the core file: Once a directory and file pattern are specified, you can optionally adjust which portions of the processes address space (e.g., text segment, heap, ISM, etc.) will be written to the core file. To ease debugging, I like to configure coreadm to dump everything with the"-G all" option: Since core files are typically created at odd working hours, I also like to configure coreadm to log messages to syslog indicating that a core file was created…
$ read more →Measuring system call time with procsystime
When debugging application performance problems related to high system time, I typically start my analysis by watching the system calls the application is issuing, and measuring how much time is spent in each system call. Gathering this information is simple with DTrace syscall provider, and the DTraceToolkit comes with the procsystime script to allow admins to easily analyze system call behavior. To use procsystime to measure how much time the sshd proceses are spending in each system call, we can run procsystime with the "-T" option to get the total time spent in all system calls, the "-n" option, and the process name to analyze (in the example below, using the string "sshd" will cause procsystime to analyze the system call behavior for all processes named sshd): The output will contain the name of the system call in the left hand column, and the time spent in that system call in the right hand column. There are additional options to display the number of calls to each system call, and you can also filter by process id if you want to measure a specific process…
$ read more →