[CentOS] Centos/Linux Disk Caching, might be OT in some ways
JohnS
jses27 at gmail.comMon Jan 25 00:42:58 UTC 2010
- Previous message: [CentOS] Centos/Linux Disk Caching, might be OT in some ways
- Next message: [CentOS] Centos/Linux Disk Caching, might be OT in some ways
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, 2010-01-25 at 01:09 +0800, Noob Centos Admin wrote: > e.g. the table may currently have rows with 20 fields and total > 1KB/row, but very often say only 5/20 fields are used in actual > processing. Reading x rows from this table may access x inodes which > would not fit into the cache/memory. 20 feilds or columns is really nothing. BUT That's dependant on the type of data being inserted. > However if now I break the table into two parts with those 5 fields > into a smaller table, there would be a speed increase since the > reading the same x rows from this table would only access 1/x inodes. > Further more, these would more likely fit into the disk/memory cache > for even faster access. Ok so break the one table down create 2 or more, then you will have "Joins" & clustered indexes thus slowing you down more possibly. That is greatly dependant on your select, delete, and update scripts. > Or would I simply be duplicating what the DBMS's index files would > already be doing and therefore see no improvement? Possibly very correct, but Nate is very correct on how you are accessing the DB ie direct i/o also. Your fastest access come in optimized SPROCS and Triggers and TSQL. Slam enough memory into the server and load it in memory. If speed is what your after why are you worried about VFS? CentOS does support Raw Disk Access (no filesystem). John
- Previous message: [CentOS] Centos/Linux Disk Caching, might be OT in some ways
- Next message: [CentOS] Centos/Linux Disk Caching, might be OT in some ways
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the CentOS mailing list