| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1181.1 | Potential bottleneck for single process | HOTWTR::LASZLO_RE | | Mon Sep 14 1992 22:06 | 10 |
| I would like to know of ESE50 issues. I suspect one of my customers is
hitting a limitation that Rdb issues synchronous I/O's, and with a
single heavy-I/O process, even a VAX 6000-620 cannot issue I/O's fast
enough to get more than 300 I/O's per second.
(I am still researching this one - consider this note hearsay
evidence).
-Rebecca Laszlo
|
| 1181.2 | | UKEDU::SMITHB | Bazzoo� | Tue Sep 15 1992 14:37 | 6 |
| > hitting a limitation that Rdb issues synchronous I/O's, and with a
> single heavy-I/O process, even a VAX 6000-620 cannot issue I/O's fast
Rdb does asynchronous I/Os
Barry
|
| 1181.3 | Read = SYNCH, write = ASYNCH | COPCLU::BRUNSGAARD | The olympic sleep | Wed Sep 16 1992 22:17 | 27 |
| But Barry
Rdb does SYNCHRONOUS read I/O's but write ASYNCH.
While there are specific cases where ASYNCH READ makes sence
- Sequential acces, Union operations and processing OR predicates
springs to mind
all solutions require quite *interesting* code to handle failure
situations.
Anyway it is indeed quite possible that you see this bottle neck, but
ONLY for READ ONLY operations. Rdb is EASILY capable of requesting more that
1000 I/O's pr. second for write operations (I have manged to get my
model 31(cheapest model) 00 request >300I/O's (and actualy DOING > 100
I/O's per second in a RZ drive !!!).
Also the limitation is tightly coupled to the size of the CPU. Ie a
7000 machine would have a higher limit than a 6600, and finally the
limit is on a per user basis !
Ie two users cn BOTH request 300 I/O's per second (if 300 is the
limit).
fwiw
Lars
Ps. Note that 300 I/O's is an arbitrary limit used to exemplify the
explanation !!
|