It stands for input output. people here usually test disk io. it shows how fast the hard drive is at reading / writing to the disk. the higher the better
depends on the .txt file. how big is it are you reading it all ? can it be put in ram etc
"Disk i/o" is disk input/output, in other words, reading a file and writing a file, as exussum said. I/O speed is typically measured in MB/s (megabytes per second).
There's not a lot you can do on your end to improve disk i/o; it will mostly be up to your host to optimize their nodes for best performance. Typically a .txt file like the one you described will not weigh heavily on disk performance, that's next to nothing.
IO is an exchange of data between RAM and devices such as keyboard, disk, monitor etc. You write something to disk - it is disk IO operation. You send a packet to the net - it is network-card IO operation.
In our case you assume it is disk IO.
Will like 100 reads per minute on a .txt file make it high?
IO is just a process (not in the terms of OS, but our, simple process), an operation. We can measure it in megabytes per second, packets per second etc. 100 reads per minute means that you have performed high-level operation 'read' 100 times and nothing more.
It seems that still you don't understand the concept.
Any disk operation, is callen an I/O or input/output operation.
So, any process that you run causes disk operations because you read the executables from the disk right? (and libraries, and other stuff).
And particularly apache will cause I/O operations at the moment that someone request a webpage because apache must read that file from the disk.
Finally, when we talk about bad IO or good IO, we talk about the speed of this disk operations. If the disk is slow (bad I/O or slow I/O), your processes that use disk operations can get slow (e.g. your websites can get slow, or your database queries can be slow, etc).
So if I had Apache processes spiking to 100 but had MaxSpareServers at like 5, it would cause a lot more bad IO than if I had MaxSpareServers at 90?
If MaxSpareServers is high to handle the spikes, that's less creation of processes as they are kept open in memory, right? Or is that a different type of IO? Or is that CPU?
I understand that a ton of page views would cause disk IO as you explained from say the contents of the .php file being read to be served to the user.
Well, you are talking about a more specific situation.
@Naruto said: So if I had Apache processes spiking to 100 but had MaxSpareServers at like 5, it would cause a lot more bad IO than if I had MaxSpareServers at 90?
IMHO, probably having more or less spare servers (apache threads) won't make a difference in the I/O.
And more than this, having more spare servers probably will cause less I/O load (less I/O operations), because the processes use your extra memory as cache, so if you try to get the same file, there is some probability to get the file from memory cache and not getting it from disk. But I don't know, to get a real answer you require a "complex" suite of tests and monitoring tools.
@Naruto said: If MaxSpareServers is high to handle the spikes, that's less creation of processes as they are kept open in memory, right? Or is that a different type of IO? Or is that CPU?
Well, if I remember correctly, let's suppose you get an spike, then your Apache will start to create processes (threads, properly), so, you will make some I/O operations to create these threads (a little note below). Now, when the spike stops, after some time these process will die. To kept them in memory, probably what you need to tune is the MinSpareServers parameter.
Note: I don't know how is the process that follow the main Apache thread to create a new process, but probably it just forks itself to a new children, which probably won't lead to big I/O operations.
Finally, I think the creation of new Apache processes must not be your biggest concern, because I think the main I/O "consumer" is the moment when you read the files (the .php as you said), and probably a lot more of I/O load when you read from your database, if you use one.
Comments
It stands for input output. people here usually test disk io. it shows how fast the hard drive is at reading / writing to the disk. the higher the better
depends on the .txt file. how big is it are you reading it all ? can it be put in ram etc
Let's say it's read once per second.
Let's say it has like 30 characters in it.
Let's say it's written into 4 times a minute.
Then what?
"Disk i/o" is disk input/output, in other words, reading a file and writing a file, as exussum said. I/O speed is typically measured in MB/s (megabytes per second).
There's not a lot you can do on your end to improve disk i/o; it will mostly be up to your host to optimize their nodes for best performance. Typically a .txt file like the one you described will not weigh heavily on disk performance, that's next to nothing.
As vps6net said, that's really nothing as that could be cached in the memory.
But I have to ask, why are you reading it every second?
You are only writing to it every 15sec, why read it more?
IO is an exchange of data between RAM and devices such as keyboard, disk, monitor etc. You write something to disk - it is disk IO operation. You send a packet to the net - it is network-card IO operation.
In our case you assume it is disk IO.
IO is just a process (not in the terms of OS, but our, simple process), an operation. We can measure it in megabytes per second, packets per second etc. 100 reads per minute means that you have performed high-level operation 'read' 100 times and nothing more.
Can Apache processes cause IO?
Yes, apache processes will utilize IO. Basically, all of the software on your server will utilize IO. apache, mysql, php, syslogd - all of it.
syslogd can be a real mess if you aren't careful.
We've seen some instances of it hit 5 - 10MB/sec when things are going mental.
Francisco
It seems that still you don't understand the concept.
Any disk operation, is callen an I/O or input/output operation.
So, any process that you run causes disk operations because you read the executables from the disk right? (and libraries, and other stuff).
And particularly apache will cause I/O operations at the moment that someone request a webpage because apache must read that file from the disk.
Finally, when we talk about bad IO or good IO, we talk about the speed of this disk operations. If the disk is slow (bad I/O or slow I/O), your processes that use disk operations can get slow (e.g. your websites can get slow, or your database queries can be slow, etc).
I hope this is more clear now with some examples.
I really still didn't understand the concept.
You just made it a LOT more clear.
So if I had Apache processes spiking to 100 but had MaxSpareServers at like 5, it would cause a lot more bad IO than if I had MaxSpareServers at 90?
If MaxSpareServers is high to handle the spikes, that's less creation of processes as they are kept open in memory, right? Or is that a different type of IO? Or is that CPU?
I understand that a ton of page views would cause disk IO as you explained from say the contents of the .php file being read to be served to the user.
Well, you are talking about a more specific situation.
IMHO, probably having more or less spare servers (apache threads) won't make a difference in the I/O.
And more than this, having more spare servers probably will cause less I/O load (less I/O operations), because the processes use your extra memory as cache, so if you try to get the same file, there is some probability to get the file from memory cache and not getting it from disk. But I don't know, to get a real answer you require a "complex" suite of tests and monitoring tools.
Well, if I remember correctly, let's suppose you get an spike, then your Apache will start to create processes (threads, properly), so, you will make some I/O operations to create these threads (a little note below). Now, when the spike stops, after some time these process will die. To kept them in memory, probably what you need to tune is the MinSpareServers parameter.
Note: I don't know how is the process that follow the main Apache thread to create a new process, but probably it just forks itself to a new children, which probably won't lead to big I/O operations.
Finally, I think the creation of new Apache processes must not be your biggest concern, because I think the main I/O "consumer" is the moment when you read the files (the .php as you said), and probably a lot more of I/O load when you read from your database, if you use one.
Man someone needs to hire you somewhere. The way you describe things I like understand it better.
Hehe, thanks I just try to explain how I understand it :P