The last message was so long that this may have been missed: it's not
just the DB that shows the slowdown. It's general. It's just really
obvious with the DB due to visual feedback. Who would notice if gcc-3
took an extra 20 minutes to compile something ;( (I haven't really timed
it. I noticed gcc gets slower, but not timed it to see how much, so its
subjective.)
This may be irrelevant, but here's meminfo this morning:
total: used: free: shared: buffers: cached:
Mem: 1053401088 887148544 166252544 65536 242728960 552976384
Swap: 2147467264 74866688 2072600576
MemTotal: 1028712 kB
MemFree: 162356 kB
MemShared: 64 kB
Buffers: 237040 kB
Cached: 478604 kB
SwapCached: 61412 kB
Active: 421960 kB
Inact_dirty: 352208 kB
Inact_clean: 2952 kB
Inact_target: 260 kB
HighTotal: 130992 kB
HighFree: 2036 kB
LowTotal: 897720 kB
LowFree: 160320 kB
SwapTotal: 2097136 kB
SwapFree: 2024024 kB
On Sat, Sep 29, 2001 at 03:33:17PM +0100, Alan Cox wrote:
> > I ran a program that's a GUI app/front-end to a data base, on the
> > local drives. It took seconds to access a record.
>
> Is the data base doing I/O directly to a block device and not using
> O_DIRECT for one question
>
> Second question is what is in your IDE logs. The IDE layer will change
> down speeds when it hits a repeated problem (eg a DMA timeout) so if
> need be will switch back to PIO or to MWDMA.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/