FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 12-04-2007, 09:03 PM
Konstantin Svist
 
Default Slow file access

Here's the situation:

I have some large mysql db files on my main partition. For some strange
reason, some of these files are very slow to be read off the disk:
~3MB/s (I'm SCPing them to another machine). File size doesn't seem to
be relevant (other files of approximately same size are being
transferred at ~20MB/s), and the speed is not the same throughout the file.


My first thought was that the file got very fragmented (I'm fairly sure
that the partition was filled up to [almost] 100% at some point).
Usually, that can be remedied by copying the file to another location on
the same partition.. or rather, that's what would fix fragmented files
on NTFS. When I tried that, the read speed of the new file was better by
a small amount (up to ~5MB/s) - although that could be because the file
was still in the memory cache.


I also thought that HD might be nearing the end of its useful lifetime
(and has to re-read the sectors, causing the horrible slowdown), but I
didn't notice any alerts from SMART (including the output of smartctl
-a, anyway)


The partition is ~60-70% full, type ext3 with noatime enabled.
Speed tests were performed by "scp myfile localhost:/dev/null"



smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model: ST3300831A
Serial Number: 3NF17FA8
Firmware Version: 3.04
User Capacity: 300,069,052,416 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 7
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Tue Dec 4 14:01:27 2007 PST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 430) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 101) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 062 050 006 Pre-fail Always - 217294
3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 25
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 081 060 030 Pre-fail Always - 8837462413
9 Power_On_Hours 0x0032 084 084 000 Old_age Always - 14629
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 59
194 Temperature_Celsius 0x0022 047 064 000 Old_age Always - 47 (Lifetime Min/Max 0/22)
195 Hardware_ECC_Recovered 0x001a 062 049 000 Old_age Always - 217294
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0
202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-04-2007, 09:44 PM
"Tod Merley"
 
Default Slow file access

On Dec 4, 2007 2:03 PM, Konstantin Svist <fry.kun@gmail.com> wrote:
> Here's the situation:
>
> I have some large mysql db files on my main partition. For some strange
> reason, some of these files are very slow to be read off the disk:
> ~3MB/s (I'm SCPing them to another machine). File size doesn't seem to
> be relevant (other files of approximately same size are being
> transferred at ~20MB/s), and the speed is not the same throughout the file.
>
> My first thought was that the file got very fragmented (I'm fairly sure
> that the partition was filled up to [almost] 100% at some point).
> Usually, that can be remedied by copying the file to another location on
> the same partition.. or rather, that's what would fix fragmented files
> on NTFS. When I tried that, the read speed of the new file was better by
> a small amount (up to ~5MB/s) - although that could be because the file
> was still in the memory cache.
>
> I also thought that HD might be nearing the end of its useful lifetime
> (and has to re-read the sectors, causing the horrible slowdown), but I
> didn't notice any alerts from SMART (including the output of smartctl
> -a, anyway)
>
> The partition is ~60-70% full, type ext3 with noatime enabled.
> Speed tests were performed by "scp myfile localhost:/dev/null"
>
>
>
>
> smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
> Home page is http://smartmontools.sourceforge.net/
>
> === START OF INFORMATION SECTION ===
> Device Model: ST3300831A
> Serial Number: 3NF17FA8
> Firmware Version: 3.04
> User Capacity: 300,069,052,416 bytes
> Device is: Not in smartctl database [for details use: -P showall]
> ATA Version is: 7
> ATA Standard is: Exact ATA specification draft version not indicated
> Local Time is: Tue Dec 4 14:01:27 2007 PST
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
>
> === START OF READ SMART DATA SECTION ===
> SMART overall-health self-assessment test result: PASSED
>
> General SMART Values:
> Offline data collection status: (0x82) Offline data collection activity
> was completed without error.
> Auto Offline Data Collection: Enabled.
> Self-test execution status: ( 0) The previous self-test routine completed
> without error or no self-test has ever
> been run.
> Total time to complete Offline
> data collection: ( 430) seconds.
> Offline data collection
> capabilities: (0x5b) SMART execute Offline immediate.
> Auto Offline data collection on/off support.
> Suspend Offline collection upon new
> command.
> Offline surface scan supported.
> Self-test supported.
> No Conveyance Self-test supported.
> Selective Self-test supported.
> SMART capabilities: (0x0003) Saves SMART data before entering
> power-saving mode.
> Supports SMART auto save timer.
> Error logging capability: (0x01) Error logging supported.
> General Purpose Logging supported.
> Short self-test routine
> recommended polling time: ( 1) minutes.
> Extended self-test routine
> recommended polling time: ( 101) minutes.
>
> SMART Attributes Data Structure revision number: 10
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
> 1 Raw_Read_Error_Rate 0x000f 062 050 006 Pre-fail Always - 217294
> 3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
> 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 25
> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
> 7 Seek_Error_Rate 0x000f 081 060 030 Pre-fail Always - 8837462413
> 9 Power_On_Hours 0x0032 084 084 000 Old_age Always - 14629
> 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
> 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 59
> 194 Temperature_Celsius 0x0022 047 064 000 Old_age Always - 47 (Lifetime Min/Max 0/22)
> 195 Hardware_ECC_Recovered 0x001a 062 049 000 Old_age Always - 217294
> 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
> 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
> 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
> 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0
> 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0
>
> SMART Error Log Version: 1
> No Errors Logged
>
> SMART Self-test log structure revision number 1
> No self-tests have been logged. [To run self-tests, use: smartctl -t]
>
>
> SMART Selective self-test log data structure revision number 1
> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
> 1 0 0 Not_testing
> 2 0 0 Not_testing
> 3 0 0 Not_testing
> 4 0 0 Not_testing
> 5 0 0 Not_testing
> Selective self-test flags (0x0):
> After scanning selected spans, do NOT read-scan remainder of disk.
> If Selective self-test is pending on power-up, resume after 0 minute delay.
>
>
> --
> fedora-list mailing list
> fedora-list@redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>

Hi Konstantin Svist!

If I understand the data:

Lots of seek errors - lots of ECC recoveries - running very warm (117
degrees Farenheit). Check for cooling issues. Low level format if
possible.

Sounds kind of like the little guy has worked very hard for you the
last year and a half! Yes, maybe time to change him out.

Just some thoughts!

Tod

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-04-2007, 10:09 PM
Konstantin Svist
 
Default Slow file access

Tod Merley wrote:

On Dec 4, 2007 2:03 PM, Konstantin Svist <fry.kun@gmail.com> wrote:


Here's the situation:

I have some large mysql db files on my main partition. For some strange
reason, some of these files are very slow to be read off the disk:
~3MB/s (I'm SCPing them to another machine). File size doesn't seem to
be relevant (other files of approximately same size are being
transferred at ~20MB/s), and the speed is not the same throughout the file.

My first thought was that the file got very fragmented (I'm fairly sure
that the partition was filled up to [almost] 100% at some point).
Usually, that can be remedied by copying the file to another location on
the same partition.. or rather, that's what would fix fragmented files
on NTFS. When I tried that, the read speed of the new file was better by
a small amount (up to ~5MB/s) - although that could be because the file
was still in the memory cache.

I also thought that HD might be nearing the end of its useful lifetime
(and has to re-read the sectors, causing the horrible slowdown), but I
didn't notice any alerts from SMART (including the output of smartctl
-a, anyway)

The partition is ~60-70% full, type ext3 with noatime enabled.
Speed tests were performed by "scp myfile localhost:/dev/null"



----SNIP


Hi Konstantin Svist!

If I understand the data:

Lots of seek errors - lots of ECC recoveries - running very warm (117
degrees Farenheit). Check for cooling issues. Low level format if
possible.

Sounds kind of like the little guy has worked very hard for you the
last year and a half! Yes, maybe time to change him out.

Just some thoughts!

Tod




Thanks, Tod!

Just now I checked the value of "195 Hardware_ECC_Recovered" - it seems
to be increasing by a large amount every second. However, the same thing
is happening on most of my HDs (I see that number increase by ~15-20K/s
on the machine with the slow file, and ~45K/s on some 1-month-old SATA
drives (those might have a different load, however).
Is this normal? (these are all HD-intensive servers, BTW, mostly DB
accesses)



I also remember hearing on this list that it's not certain how to read
some SMART values... look for thread "Fedora May Be Killing Your
Laptop's Hard Drive?". The attribute in question was "193
Load_Cycle_Count" but maybe the same thing applies to the other "raw data"?




--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-04-2007, 10:53 PM
"Tod Merley"
 
Default Slow file access

On Dec 4, 2007 3:09 PM, Konstantin Svist <fry.kun@gmail.com> wrote:
> Tod Merley wrote:
> > On Dec 4, 2007 2:03 PM, Konstantin Svist <fry.kun@gmail.com> wrote:
> >
> >> Here's the situation:
> >>
> >> I have some large mysql db files on my main partition. For some strange
> >> reason, some of these files are very slow to be read off the disk:
> >> ~3MB/s (I'm SCPing them to another machine). File size doesn't seem to
> >> be relevant (other files of approximately same size are being
> >> transferred at ~20MB/s), and the speed is not the same throughout the file.
> >>
> >> My first thought was that the file got very fragmented (I'm fairly sure
> >> that the partition was filled up to [almost] 100% at some point).
> >> Usually, that can be remedied by copying the file to another location on
> >> the same partition.. or rather, that's what would fix fragmented files
> >> on NTFS. When I tried that, the read speed of the new file was better by
> >> a small amount (up to ~5MB/s) - although that could be because the file
> >> was still in the memory cache.
> >>
> >> I also thought that HD might be nearing the end of its useful lifetime
> >> (and has to re-read the sectors, causing the horrible slowdown), but I
> >> didn't notice any alerts from SMART (including the output of smartctl
> >> -a, anyway)
> >>
> >> The partition is ~60-70% full, type ext3 with noatime enabled.
> >> Speed tests were performed by "scp myfile localhost:/dev/null"
> >>
> >>
> >>
> >> ----SNIP
> >
> > Hi Konstantin Svist!
> >
> > If I understand the data:
> >
> > Lots of seek errors - lots of ECC recoveries - running very warm (117
> > degrees Farenheit). Check for cooling issues. Low level format if
> > possible.
> >
> > Sounds kind of like the little guy has worked very hard for you the
> > last year and a half! Yes, maybe time to change him out.
> >
> > Just some thoughts!
> >
> > Tod
> >
> >
>
> Thanks, Tod!
>
> Just now I checked the value of "195 Hardware_ECC_Recovered" - it seems
> to be increasing by a large amount every second. However, the same thing
> is happening on most of my HDs (I see that number increase by ~15-20K/s
> on the machine with the slow file, and ~45K/s on some 1-month-old SATA
> drives (those might have a different load, however).
> Is this normal? (these are all HD-intensive servers, BTW, mostly DB
> accesses)
>
>
> I also remember hearing on this list that it's not certain how to read
> some SMART values... look for thread "Fedora May Be Killing Your
> Laptop's Hard Drive?". The attribute in question was "193
> Load_Cycle_Count" but maybe the same thing applies to the other "raw data"?
>
>
>
> --
>
> fedora-list mailing list
> fedora-list@redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>

Hi again Konstantin Svist!

I am no expert, simply an interested party.

I did find this study, however:

http://research.google.com/archive/disk_failures.pdf

Good Reading!

Tod

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-04-2007, 11:05 PM
Rick Stevens
 
Default Slow file access

On Tue, 2007-12-04 at 15:53 -0800, Tod Merley wrote:
> On Dec 4, 2007 3:09 PM, Konstantin Svist <fry.kun@gmail.com> wrote:
> > Tod Merley wrote:
> > > On Dec 4, 2007 2:03 PM, Konstantin Svist <fry.kun@gmail.com> wrote:
> > >
> > >> Here's the situation:
> > >>
> > >> I have some large mysql db files on my main partition. For some strange
> > >> reason, some of these files are very slow to be read off the disk:
> > >> ~3MB/s (I'm SCPing them to another machine). File size doesn't seem to
> > >> be relevant (other files of approximately same size are being
> > >> transferred at ~20MB/s), and the speed is not the same throughout the file.
> > >>
> > >> My first thought was that the file got very fragmented (I'm fairly sure
> > >> that the partition was filled up to [almost] 100% at some point).
> > >> Usually, that can be remedied by copying the file to another location on
> > >> the same partition.. or rather, that's what would fix fragmented files
> > >> on NTFS. When I tried that, the read speed of the new file was better by
> > >> a small amount (up to ~5MB/s) - although that could be because the file
> > >> was still in the memory cache.
> > >>
> > >> I also thought that HD might be nearing the end of its useful lifetime
> > >> (and has to re-read the sectors, causing the horrible slowdown), but I
> > >> didn't notice any alerts from SMART (including the output of smartctl
> > >> -a, anyway)
> > >>
> > >> The partition is ~60-70% full, type ext3 with noatime enabled.
> > >> Speed tests were performed by "scp myfile localhost:/dev/null"
> > >>
> > >>
> > >>
> > >> ----SNIP
> > >
> > > Hi Konstantin Svist!
> > >
> > > If I understand the data:
> > >
> > > Lots of seek errors - lots of ECC recoveries - running very warm (117
> > > degrees Farenheit). Check for cooling issues. Low level format if
> > > possible.
> > >
> > > Sounds kind of like the little guy has worked very hard for you the
> > > last year and a half! Yes, maybe time to change him out.
> > >
> > > Just some thoughts!
> > >
> > > Tod
> > >
> > >
> >
> > Thanks, Tod!
> >
> > Just now I checked the value of "195 Hardware_ECC_Recovered" - it seems
> > to be increasing by a large amount every second. However, the same thing
> > is happening on most of my HDs (I see that number increase by ~15-20K/s
> > on the machine with the slow file, and ~45K/s on some 1-month-old SATA
> > drives (those might have a different load, however).
> > Is this normal? (these are all HD-intensive servers, BTW, mostly DB
> > accesses)
> >
> >
> > I also remember hearing on this list that it's not certain how to read
> > some SMART values... look for thread "Fedora May Be Killing Your
> > Laptop's Hard Drive?". The attribute in question was "193
> > Load_Cycle_Count" but maybe the same thing applies to the other "raw data"?
> >
> >
> >
> > --
> >
> > fedora-list mailing list
> > fedora-list@redhat.com
> > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> >
>
> Hi again Konstantin Svist!
>
> I am no expert, simply an interested party.
>
> I did find this study, however:
>
> http://research.google.com/archive/disk_failures.pdf

Interesting stuff on SMART itself at

http://www.linuxjournal.com/article/6983

At least you'll know how to read those values.
----------------------------------------------------------------------
- Rick Stevens, Principal Engineer rstevens@internap.com -
- CDN Systems, Internap, Inc. http://www.internap.com -
- -
- The gene pool could use a little chlorine. -
----------------------------------------------------------------------

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-04-2007, 11:16 PM
Claude Jones
 
Default Slow file access

On Tue December 4 2007, Rick Stevens wrote:
> > I did find this study, however:
> >
> > http://research.google.com/archive/disk_failures.pdf
>
> Interesting stuff on SMART itself at
>
> ********http://www.linuxjournal.com/article/6983
>
> At least you'll know how to read those values.

It's an interesting read, Rick, but, I recommend the Google study as a must
read for those concerned with disk failure. It turns out SMART is not so
smart. Further, there are some old shibboleths regarding heat that are
questioned by the Google findings.

There's only one sure fire protection against SDF (sudden disk failure) in my
view, and it's called "backup-early-and-often"

--
Claude Jones
Brunswick, MD, USA

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-04-2007, 11:22 PM
Rick Stevens
 
Default Slow file access

On Tue, 2007-12-04 at 19:16 -0500, Claude Jones wrote:
> On Tue December 4 2007, Rick Stevens wrote:
> > > I did find this study, however:
> > >
> > > http://research.google.com/archive/disk_failures.pdf
> >
> > Interesting stuff on SMART itself at
> >
> > http://www.linuxjournal.com/article/6983
> >
> > At least you'll know how to read those values.
>
> It's an interesting read, Rick, but, I recommend the Google study as a must
> read for those concerned with disk failure. It turns out SMART is not so
> smart. Further, there are some old shibboleths regarding heat that are
> questioned by the Google findings.
>
> There's only one sure fire protection against SDF (sudden disk failure) in my
> view, and it's called "backup-early-and-often"

Yup. I have a couple of Terrastations for that purpose at home. I also
burn tons of DVDs. I wish I drank more and had stock in sheet cork
factories as I make (and thus have) lots and lots of coasters (data DVDs
>6 months old). Last count about 50. :-)

----------------------------------------------------------------------
- Rick Stevens, Principal Engineer rstevens@internap.com -
- CDN Systems, Internap, Inc. http://www.internap.com -
- -
- "I'd explain it to you, but your brain might explode." -
----------------------------------------------------------------------

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-06-2008, 05:31 PM
"Keith Clark"
 
Default Slow file access

Why is it since upgrading to 8.10 that when I want to access the file
system, and want the properties of a file in Nautilus, the window goes
gray and it takes forever to see the results. If at all.

Everything relating to Nautilus seems to be running in slow motion now.

Keith

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 

Thread Tools




All times are GMT. The time now is 08:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org