Signs of I/O problems
If the performance of the website or the application leaves much to be desired, the cause must first be found. In addition to the CPU load and the use of the main memory, you can check the performance under Unix with the command top also detect the utilization of the mass memory. The so-called "iowait" value or the "wait-states" when accessing the mass storage are a good indicator. If this value is too high (even higher than in our example below), this could indicate a bottleneck in I/O access to the mass storage.
Monitoring tools are also a good way to assess I/O utilization, of course. We at ScaleUp use here check_mk. This allows us and our customers to keep track of their systems in terms of utilization data.
There are I/O bottlenecks - now what?
Once an I/O bottleneck has been identified, the reasons for it must be determined. The number of I/O requests can often be significantly reduced by adapting the configuration of the applications. For example, the use of caches (e.g. Redis, Memcached) or the optimization of database queries can be considered here.
A change in the technology used can also be a solution. One example is the full-text search integrated in the widely used CMS Typo3. Without any further adjustments, the search there runs via the database. For large websites with several thousand documents, this type of search is very inefficient. The actual database queries cover a lot of rows. This could actually be solved by intelligent design of these queries. In practice, however, this is not possible because the database queries are generated by the Typo3 framework. The best solution in this specific case would be to use an external search engine such as Apache Solr or Elasticsearch.
Increase I/O performance
Sometimes, however, improving the I/O performance of the mass storage is the only practical solution. For this purpose, it is a good idea to use faster mass storage such as SSD or NVMe. For example, some IaaS providers, such as our Open Cloud, offer the option of using instances (VMs) with local SSD storage - in contrast to the network-based storage that is otherwise used. However, it must be noted here that the storage is only located locally on a physical server and is no longer available if this server fails. However, this is not a problem for applications that are operated redundantly with several instances.
We are also increasingly using flash storage (SSD, NVMe) in the central mass storage of our IaaS cloud. However, due to network latency, this cannot reach the speed of the local SSD storage.
Do you have questions or special I/O requirements? Please feel free to contact Contact with us.
