Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 33

Thread: Very slow SDD/HDD performance

  1. #11
    Join Date
    Jan 2006
    Location
    Örebro, Sweden
    Beans
    491

    Re: Very slow SDD/HDD performance

    Now I have moved /var to the SSD, and at the moment things are blazing. However, as I mentioned in my original post, the problem with slow IO performance only happened sometimes, not all the time. So I don't dare to consider the problem solved just yet.

    Regarding the /tmp mount point: yes, that was done manually. I wanted to move both /var and /tmp away from the SSD, to reduce the amount of writes to it. I hope putting /var back on the SSD won't kill it prematurely.

  2. #12
    Join Date
    Jan 2007
    Beans
    3,202

    Re: Very slow SDD/HDD performance

    My main OS (debian sid) has been running on a SSD (OCZ RevoDrive) for over 2 years, including /var, and there are no signs of SSD wear issues -- this desktop runs 24/7 and only gets rebooted for new kernels. I also mount /tmp on a tmpfs, as well as /var/spool. You can mount /var/log on a tmpfs, but you'll lose your logs every reboot, so ......
    Intel Core i7-950 / Asus P6X58D-E / Nvidia GTX480 / siduction 64-bit on OCZ Revodrive SSD / KDE4.10.2/ Kubuntu 13.04

  3. #13
    Join Date
    Aug 2011
    Location
    52° N 6° E
    Beans
    2,610
    Distro
    Xubuntu 14.04 Trusty Tahr

    Re: Very slow SDD/HDD performance

    It seems it's actually allowed to put /var on a different partition: http://refspecs.linuxfoundation.org/...ROOTFILESYSTEM

    If I'm not mistaken SSD wear depends on the number of erase cycles, not the number of writes. Only once in every so many lines written to a log (depending on the physical block size of the drive) one block is erased, whilst normal updates erase many blocks simultaniously.

  4. #14
    Join Date
    Jan 2007
    Beans
    3,202

    Re: Very slow SDD/HDD performance

    Yes it's perfectly "legal" to mount /var on its own partition, however for home/single user PCs that is not a commonly-needed configuration. There is some issue with the OP's system in which it appears to get into a thrashing or cache-reading mode for ridiculous periods of time, so we may learn something by going back to a simpler and more conventional configuration. (Or we may not ....).
    Intel Core i7-950 / Asus P6X58D-E / Nvidia GTX480 / siduction 64-bit on OCZ Revodrive SSD / KDE4.10.2/ Kubuntu 13.04

  5. #15
    Join Date
    Jan 2006
    Location
    Örebro, Sweden
    Beans
    491

    Re: Very slow SDD/HDD performance

    Now I have suspended and resumed the laptop once, and I'm back to the old behaviour again. So it might be something with suspend/hibernate rather than the partitioning? Though I don't understand how.

    I know that SSD partitions also must be aligned the right way. Just to double-check, here's the output of fdisk
    Code:
    > sudo fdisk -lu /dev/sdb
    
    Disk /dev/sdb: 128.0 GB, 128035676160 bytes
    255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x9409c39e
    
       Device Boot      Start         End      Blocks   Id  System
    /dev/sdb1              63       80324       40131   de  Dell Utility
    /dev/sdb2   *       81920    21676031    10797056    7  HPFS/NTFS/exFAT
    /dev/sdb3        21676032   134957281    56640625    7  HPFS/NTFS/exFAT
    /dev/sdb4       134959102   250068991    57554945    5  Extended
    /dev/sdb5       134959104   250068991    57554944   83  Linux
    The root partition is on /dev/sdb5, and that partition starts on a number that is divisible by 2048, which is as it should, as far as I know. Some of the other (default Dell) partitions are not aligned that way, but that shouldn't matter, should it?

  6. #16
    Join Date
    Jan 2007
    Beans
    3,202

    Re: Very slow SDD/HDD performance

    Right -- that first partition is not aligned, but I don't see why that would have any influence on the Linux system's performance, and the first partition should rarely if ever experience an erase operation, so ......

    Hmmmm. I wonder if the tmpfs filesystems survive a suspend/resume cycle with all data intact? Or if the suspend operation interferes with the tmpfs filesystems which are also in memory? I don't use suspend on my desktop system so I don't know whether that could cause an issue with the filesystems that are mounted as tmpfs. It would interesting to know whether you have the thrashing problem at any time during an extended uptime, or whether it only crops up after resuming from suspend.
    Intel Core i7-950 / Asus P6X58D-E / Nvidia GTX480 / siduction 64-bit on OCZ Revodrive SSD / KDE4.10.2/ Kubuntu 13.04

  7. #17
    Join Date
    Jan 2006
    Location
    Örebro, Sweden
    Beans
    491

    Re: Very slow SDD/HDD performance

    It's definitely related to suspend. I did a reboot this morning, this time with also /tmp monted on the SSD. Everything worked fine for 2.5 hours until I suspended. Now that I have resumed, the slowness problem is back.

    Another observation is that also kwin is slower after suspend/resume. Slower as in high latency. There is a lag of about one second; for example, between me pressing alt-tab and the window list appearing. Similarly, when hovering the mouse over an entry in the task bar, it takes a second or two until the thumbnail image of that window is displayed.

    My problem seems to be trickier than I thought...

  8. #18
    Join Date
    Jan 2006
    Location
    Örebro, Sweden
    Beans
    491

    Re: Very slow SDD/HDD performance

    I'm going through the log files, trying to see if there's any indication there of what is happening when suspending and resuming. One error that always comes up is in kern.log

    PM: Device 00:0a failed to resume: error -19

    There's a post in the LinuxQuestions forum about this error message here. I tried the suggestion of listing the PCI devices with "lspci -vt", but the output does not mention a device 00:0a.

  9. #19
    Join Date
    Jan 2006
    Location
    Örebro, Sweden
    Beans
    491

    Re: Very slow SDD/HDD performance

    I'll keep using this thread to document my trouble shooting, in the hope that it will be helpful in the future.

    Regarding the 00:0a device, that seems to be a PS/2 controller. "dmesg | grep 00:0a" outputs
    Code:
    > dmesg |grep 00:0a
    [    0.572736] pnp 00:0a: [io  0x0060]
    [    0.572738] pnp 00:0a: [io  0x0064]
    [    0.572742] pnp 00:0a: [irq 1]
    [    0.572776] pnp 00:0a: Plug and Play ACPI device, IDs PNP0303 (active)
    [ 3798.386502] PM: Device 00:0a failed to restore: error -19
    and looking for that PNP0303, I get
    Code:
    > dmesg |grep PNP0303
    [    0.572776] pnp 00:0a: Plug and Play ACPI device, IDs PNP0303 (active)
    [    1.064892] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
    I've looked around a little to see if I can just disable the i8042 module, but i8042 is not included when I run "lsmod"; however, there is a directory for it in /sys/module/i8042/. Not sure how or if I can disable it, but then again, I'm not at all sure that it is this module that causes my slowness problems.

    A more relevant note is that I have tried hibernate also (once), and when resuming from hibernate, the system is still OK. It seems to be only when resuming from suspend that the problem pops up. Also, just closing the laptops lid and blanking the screen (no suspend or hibernate) does not cause a problem.

    I will post again when I have gathered more data.

  10. #20
    Join Date
    Jan 2007
    Beans
    3,202

    Re: Very slow SDD/HDD performance

    Good job of troubleshooting!

    I'm still suspicious that something is being lost from the tmpfs filesystems during suspend. Note that in a hibernate, they get written to disk, but in suspend, the entire running system gets written to memory. That might explain why hibernate works but suspend does not.
    Intel Core i7-950 / Asus P6X58D-E / Nvidia GTX480 / siduction 64-bit on OCZ Revodrive SSD / KDE4.10.2/ Kubuntu 13.04

Page 2 of 4 FirstFirst 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •