UNIXy

This error is not specific to Litespeed but can be encountered while building PHP with MySQL support on 64-bit systems. The fix is to tell the build that the MySQL client is indeed installed, but in a different directory, by adding the following flag to the configure line in Litespeed:

--with-libdir=lib64

The reason being the build doesn’t know at this point that it is dealing with a 64-bit OS. If adding the above switch does not work, be sure to install the MySQL client and libraries.

That’s all folks!

Joe Break-Fix build, client, lib64, lightspeed, litespeed, MySQL, PHP

There are many types of clusters. The one I am going to cover in this post is a Web cluster. In other words, it is a cluster of several servers built to serve Web pages. It is a made up of Web servers, database servers, and file servers. You may ask, why not deploy only one server and install the Web, database, and file server? There comes a time when one single server cannot sustain the increase in traffic. The high number of visitors exceeds the capacity of the server. Be it processor power, memory availability, disk IOPS, or network IO.

Cluster

Building clusters is not for everyone. It is a complex engineering task. The complexity resides in making the whole, called cluster, accomplish the tasks efficiently and seamlessly. It becomes even more complex when one implements load balancing and database replication. Load balancing is the act of distributing tasks across two or more server with identical configurations. Database replication is the synchronization of database tables and meta data across two or more servers. Having two identical databases scales out well especially when it has been designated as the bottleneck.

Advanced Cluster

Too often I get asked, why not deploy a monster server with 32 cores and 64GB of memory instead of building a cluster? While such server might or might not sustain the traffic, there are many points that need to be thought out. The truth is such monster server is cost prohibitive. The price to value is too high and not worth it. The reason being there is currently no commodity server that can handle 32 cores. One would need a considerable budget. For much less, one can get a 32-core cluster. The other point to consider is the fact that the motherboard bus will not be able to sustain the throughput required for a high traffic server. It will not be able to seamlessly pull 64GB/s in and out of the memory system.

Another important point is disaster recovery, one would need another equally powerful server or a very aggressive (read extremely expensive) part-replacement contract. On the other hand, commodity hardware is so affordable one could keep a few spares without breaking the bank! Plus, a monster server will never handle Digg or Slashdot effects. The cluster, however, can scale to accommodate for traffic spikes.

Keep in mind that UNIXy builds clusters for current customers free of charge. The support and service is included with your purchased dedicated servers. Contact us today and we will go above and beyond to help out.

That’s all folks!

Joe Challenge cluster, database, dedicated cluster, replication, synchronization, UNIXy, web cluster, web server

Be sure to read through the previous post for a quick introduction of IOPS.

Suppose that you’re copying a 10GB file from one disk to another. Let us assume that the only bottleneck is the disks’ own IOPS, which in case is 120. We are also only focusing on the disk where the data is copied to and assume that the other disk has no IOPS limitation. Because we are writing about 10GB, the majority of the IOPS are going to be writes and not reads.

We will also assume that the disk has a block size of 64KB. In other words we are copying a maxium of 64KB of data in one operation (120 operations per second). That gives us a sustained throughput of about 7MB/s (120 * 64 * 1024). For a 10GB file, it would take about 1462 (10GB/7MB) seconds to copy the 10GB file.

UNIXy Uncategorized bandwidth, example, IOPS, throughput

IOPS stands for Input and Output Per Second. It is essentially a value that describes the raw capacity of a data storage system. It sets an expectation for performance. Some storage systems are said to be capable 120 IOPS and others 340 IOPS or much more. The number of IOPS, for most disk systems, represents a count of a mix of data reads (Output) and writes (Input) per second. By that number, one can judge how fast and responsive a disk system can be. The numbers can be obtained by performing sequential or random operations on the disk system. The best representation is random operations since it reflects a real-life usage pattern.

Disk system manufacturers obtain IOPS numbers via benchmarking. There are tools that measure disk throughput and capacity by performing several read and write tests. For example, Iometer is a tool that can measure disk system performance and produce the IOPS value for such system. One needs to be aware of the fact that some manufacturers provide the IOPS based on cached read and write tests. The latter is a best case scenario test and does not reflect real-life usage.

So what happens when a system reaches the IOPS threshold number? I did use the word “reach” because in theory the disk system will almost never exceed the advertised IOPS. Back to the question, when the system reaches the IOPS threshold, it starts queuing requests. A busy queue generally indicates a bottleneck.

How often have you found yourself with a bottlenecked 2TB disk choking after barely putting a few files? Disk size capacity has no bearing on its IOPS capacity. A 2TB disk could have the same IOPS capacity as a 250GB disk! So when does one need to upgrade the disk system or the configuration at least? We shall post a new entry on this blog with the instructions.

That’s all folks!

UNIXy Crash Course explained, IOPS