UNIX Time and UNIX Timestamps

A recent comment on my story about converting UNIX timestamps to Oracle dates prompted me to do a little extra digging on UNIX time.

UNIX time is a standard system used not only in UNIX but in many other modern computer systems. Instead of being divided into years, months, hours, minutes, etc. UNIX time is simply a number which represents the number of seconds which have passed since midnight Coordinated Universal time (UTC, the same time zone as Greenwich Mean Time, sometimes referred to as Zulu time), January 1, 1970. This date is often referred to as the UNIX epoch.

Sound like a lot of seconds? It is. At the time of this writing it has been 1,145,404,660 since the UNIX epoch, but since people like to think of dates the old fashioned way, in years, months, days, hours, minutes and seconds the computer is almost always nice enough to convert the UNIX time into the familiar date and time format, and to your local time zone.

One of the strengths of UNIX time is that when it is recorded (a point in UNIX time is typically referred to as a UNIX timestamp) it is always relative to Greenwich Mean Time. That means UNIX timestamps can be easily converted to different time zones with no ambiguity.

For all the gruesome details on UNIX time, Wikipedia has a typically thorough article on the topic.

While there are several sites on the web to convert a UNIX timestamp to human readable format and vice-verse be careful. Many sites will do the conversion based on their time zone. 4WebHelp.net provides a great page for converting both ways.

In contrast to UNIX time, Oracle Databases record time in a more traditional year, month, day, hour, minute, second manner. In order to convert Oracle dates to a different time zone you need to know what time zone the date was originally recorded in. Only recently has Oracle introduced a time datatype with a time zone attribute.

unix, time, timestamp, time zone, date, oracle, database, solaris, linux

How Big Is That UNIX Directory?

Need to know how much space a directory and its contents are taking up on your UNIX system? Here’s what I use:

du -ks directory

The du command is used to summarize disk usage. Without any flags will show you the usage in blocks for every directory and subdirectory specified. Since the number of blocks varies by operating system we add the -k option to specify that we want the output in kilobytes. In many operating systems you could also use -h for a “human-readable” output with abbreviations like B for bytes, K for kilobytes, M for megabytes and so on.

The -s option lets us gather only the sum of the directory specified. Without the -s flag we would get output on every subdirectory as well as the specified directory.

$ du -k stuff
408560 stuff/patch
104 stuff/scripts
408688 stuff

One other thing that is useful for finding the biggest files and directories where there are a lot to sift through is to use a wildcard to size up multiple directories, then pipe the output of du to the sort command like this:

$ du -ks ./* | sort -n
0 ./sdtvolcheck727
8 ./mpztaWqc
8 ./speckeysd.lock
304 ./dtdbcache_:0
408688 ./stuff

With sort we use the -n option to order things by arithmetic value rather than alphabetic value (making 8 come before 304) so we see the largest things at the bottom.

Try it out. As always check the man pages for more info.

Easy Linux CommandsFor more tips like this check out my book Easy Linux Commands, only $19.95 from Rampant TechPress.

unix, solaris, linux, sysadmin, system administration, storage, storage administration

UNIX Load Averages Explained

If you’ve spent much time working in a UNIX environment you’ve probably seen the load averages more than a few times.

load averages: 2.43, 2.96, 3.41

I have to admit that even in my sysadmin days I didn’t fully understand what these numbers were, but Zach did some digging a while ago to try to understand where these numbers are comming from.

In his blog entry from late last year, Zach sums it up quite nicely:

In short it is the average sum of the number of processes waiting in the run-queue plus the number currently executing over 1, 5, and 15 minute time periods.

The formula is a bit more complicated than that, but this serves well as a functional definition. Zach provides a bit more detail in his article and also points out Dr. Neil Gunther’s article on the topic which has as much depth on the topic as anyone could ever ask.

So what does this mean about your system?

Well, for a quick example let’s consider the output below. The load average of a system can typically be found by running top or uptime and users typically don’t need any special privileges for these commands.

load averages: 2.43, 2.96, 3.41

Here we see the one minute load average is 2.43, five minute is 2.96, and fifteen minute load average is 3.41.

Here are some conclusions we can draw from this.

  • On average, over the past one minute there have been 2.43 processes running or waiting for a resource
  • Overall the load is on a down-trend since the average number of processes running or waiting in the past minute (2.43) is lower than the average running or waiting over the past 5 minutes (2.96) and 15 minutes (3.41)
  • This system is busy, but we cannot conclude how busy solely from load averages.

It is important here to mention that the load average does not take into account the number of processes. Another critical detail is that processes could be waiting for any number of things including CPU, disk, or network.

So what we do know is that a system that has a load average significantly higher than the number of CPUs is probably pretty busy, or bogged down by some bottleneck. Conversely a system which has a load average significantly lower than the number of CPUs is probably doing just fine.

Easy Linux CommandsFor more tips like this check out my book Easy Linux Commands, only $19.95 from Rampant TechPress.

UNIX, systems administration, sysadmin, solaris, linux, load averages, system monitoring, sun, mac, osx

Oracle on Solaris: 32-bit or 64-bit

It is important for optimal performance to make sure you match up your Oracle RDBMS installation with your OS. Running a 32-bit version of Oracle on a 64-bit OS is may not give you peak performance, but also will not be able to address large segments of RAM and large files. So how do you know what your OS supports? How can you tell if that Oracle install from before you started is 64-bit? Here’s how:

Is my Operating System 64-bit?

In Solaris, from the command line (you don’t have to be root in most cases) run this command:

/usr/bin/isainfo -kv

If your OS is 64-bit, you will see output like:

64-bit sparcv9 kernel modules

If your OS is 32-bit, you will get this output:

32-bit sparc kernel modules

For Linux users

If you are running Linux, you can check your distribution with the uname command:

uname -m

The output will read x86_64 for 64-bit and i686 or similar for 32-bit.

How about this Oracle install? Is it 64-bit?

The question here is weather your Oracle binaries are 64-bit. While some of the binaries associated with Oracle may be 32-bit, the important ones will be 64 bit. To check those, follow these steps from the command line:

file oracl*

This will display the file type of your oracle binaries. If you are running 64-bit binaries, the output should look like this:

oracle: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped
oracleO: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped

If your binaries are 32-bit, the output will look like this:

oracle: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped

If you find you are running 32-bit and decide to go to 64 be careful. The switch can be a bit tricky. Read the documentation closely and make sure your service contract is payed up!

oracle, dba, database administration, database, solaris, linux, sun, sun microsystems, 32-bit, 64-bit