Desktop completely freezing on I/O operations












1















In my old system, I was already having desktop freezes on some heavy I/O operations like apt-get dist-upgrade and copying 4 GB video files. But now, it has become a lot worse: any apt-get install is enough the freeze the whole desktop, and copying the videos with nice -c 3 does not help at all, I cannot do any operation for minutes. According to man ionice, the impact of an idle I/O process on normal system activity should be zero.



One weird swap problem appeared as well: I had disabled the swap partition, and twice an OOM was triggered. But instead of killing the process that trigerred the OOM (I set vm.oom_kill_allocating_task=1), the disk started spinning and totally froze the desktop for a long time, although I had run sudo swapoff -a and checked whether it worked.



The old hardware and system:




  • Hard drive: 500 GB Toshiba

  • System: Debian 7.9 (32 bits)

  • Kernel: 3.15.10-zen-686 (Liquorix)

  • Disk scheduler: BFQ

  • Filesystem: ext4


The new hardware and system:




  • Hard drive: 1 TB Samsung

  • System: Ubuntu 15.10 (64 bits)

  • Kernel: 4.2.0-30-generic

  • Disk scheduler: Deadline (default)

  • Filesystem: encrypted LVM with Btrfs


I have found many people who have solved similar problems by changing from the CFQ scheduler to Deadline, but Deadline is the default on the Ubuntu kernel. And I already had problems with the supposedly fast BFQ disk scheduler with no encryption.










share|improve this question
















bumped to the homepage by Community 16 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.




















    1















    In my old system, I was already having desktop freezes on some heavy I/O operations like apt-get dist-upgrade and copying 4 GB video files. But now, it has become a lot worse: any apt-get install is enough the freeze the whole desktop, and copying the videos with nice -c 3 does not help at all, I cannot do any operation for minutes. According to man ionice, the impact of an idle I/O process on normal system activity should be zero.



    One weird swap problem appeared as well: I had disabled the swap partition, and twice an OOM was triggered. But instead of killing the process that trigerred the OOM (I set vm.oom_kill_allocating_task=1), the disk started spinning and totally froze the desktop for a long time, although I had run sudo swapoff -a and checked whether it worked.



    The old hardware and system:




    • Hard drive: 500 GB Toshiba

    • System: Debian 7.9 (32 bits)

    • Kernel: 3.15.10-zen-686 (Liquorix)

    • Disk scheduler: BFQ

    • Filesystem: ext4


    The new hardware and system:




    • Hard drive: 1 TB Samsung

    • System: Ubuntu 15.10 (64 bits)

    • Kernel: 4.2.0-30-generic

    • Disk scheduler: Deadline (default)

    • Filesystem: encrypted LVM with Btrfs


    I have found many people who have solved similar problems by changing from the CFQ scheduler to Deadline, but Deadline is the default on the Ubuntu kernel. And I already had problems with the supposedly fast BFQ disk scheduler with no encryption.










    share|improve this question
















    bumped to the homepage by Community 16 mins ago


    This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.


















      1












      1








      1


      1






      In my old system, I was already having desktop freezes on some heavy I/O operations like apt-get dist-upgrade and copying 4 GB video files. But now, it has become a lot worse: any apt-get install is enough the freeze the whole desktop, and copying the videos with nice -c 3 does not help at all, I cannot do any operation for minutes. According to man ionice, the impact of an idle I/O process on normal system activity should be zero.



      One weird swap problem appeared as well: I had disabled the swap partition, and twice an OOM was triggered. But instead of killing the process that trigerred the OOM (I set vm.oom_kill_allocating_task=1), the disk started spinning and totally froze the desktop for a long time, although I had run sudo swapoff -a and checked whether it worked.



      The old hardware and system:




      • Hard drive: 500 GB Toshiba

      • System: Debian 7.9 (32 bits)

      • Kernel: 3.15.10-zen-686 (Liquorix)

      • Disk scheduler: BFQ

      • Filesystem: ext4


      The new hardware and system:




      • Hard drive: 1 TB Samsung

      • System: Ubuntu 15.10 (64 bits)

      • Kernel: 4.2.0-30-generic

      • Disk scheduler: Deadline (default)

      • Filesystem: encrypted LVM with Btrfs


      I have found many people who have solved similar problems by changing from the CFQ scheduler to Deadline, but Deadline is the default on the Ubuntu kernel. And I already had problems with the supposedly fast BFQ disk scheduler with no encryption.










      share|improve this question
















      In my old system, I was already having desktop freezes on some heavy I/O operations like apt-get dist-upgrade and copying 4 GB video files. But now, it has become a lot worse: any apt-get install is enough the freeze the whole desktop, and copying the videos with nice -c 3 does not help at all, I cannot do any operation for minutes. According to man ionice, the impact of an idle I/O process on normal system activity should be zero.



      One weird swap problem appeared as well: I had disabled the swap partition, and twice an OOM was triggered. But instead of killing the process that trigerred the OOM (I set vm.oom_kill_allocating_task=1), the disk started spinning and totally froze the desktop for a long time, although I had run sudo swapoff -a and checked whether it worked.



      The old hardware and system:




      • Hard drive: 500 GB Toshiba

      • System: Debian 7.9 (32 bits)

      • Kernel: 3.15.10-zen-686 (Liquorix)

      • Disk scheduler: BFQ

      • Filesystem: ext4


      The new hardware and system:




      • Hard drive: 1 TB Samsung

      • System: Ubuntu 15.10 (64 bits)

      • Kernel: 4.2.0-30-generic

      • Disk scheduler: Deadline (default)

      • Filesystem: encrypted LVM with Btrfs


      I have found many people who have solved similar problems by changing from the CFQ scheduler to Deadline, but Deadline is the default on the Ubuntu kernel. And I already had problems with the supposedly fast BFQ disk scheduler with no encryption.







      kernel hard-disk io






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Feb 25 '16 at 23:40







      Teresa e Junior

















      asked Feb 25 '16 at 14:48









      Teresa e JuniorTeresa e Junior

      2,45753050




      2,45753050





      bumped to the homepage by Community 16 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







      bumped to the homepage by Community 16 mins ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
























          1 Answer
          1






          active

          oldest

          votes


















          0














          Apparently, the biggest issue was a swap problem. In my old system, setting vm.swappiness=100 helped me avoiding system freezes by moving pages before the memory was exhausted. On this new system, it seems to have had the opposite effect: the system was always constantly and needlessly swapping. I have purchased more RAM and totally disabled swap, and the problem was mostly solved.



          Regarding the fact that I/O operations caused desktop freezes, it seems to be because the data from the operation was being cached on RAM, and the memory used by desktop applications being thrown into the swap, which caused the system to read back from disk whenever I tried interacting with the desktop.



          With enough RAM, I/O operations have mostly no effect on desktop responsiveness, but if the desktop is left unattended for some time, there may be an initial lag while interacting with the desktop. This may be due to the kernel deciding that the system is idle enough to give a higher priority to the operation, and its data may end up filling the cache completely, dropping the pages from desktop applications.



          Regarding the disk scheduler, I have not done enough testing to know which would be the best option, but from my research, it seems that either deadline completely ignores ionice, or that ionice is specific to CFQ.






          share|improve this answer

























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f265756%2fdesktop-completely-freezing-on-i-o-operations%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            0














            Apparently, the biggest issue was a swap problem. In my old system, setting vm.swappiness=100 helped me avoiding system freezes by moving pages before the memory was exhausted. On this new system, it seems to have had the opposite effect: the system was always constantly and needlessly swapping. I have purchased more RAM and totally disabled swap, and the problem was mostly solved.



            Regarding the fact that I/O operations caused desktop freezes, it seems to be because the data from the operation was being cached on RAM, and the memory used by desktop applications being thrown into the swap, which caused the system to read back from disk whenever I tried interacting with the desktop.



            With enough RAM, I/O operations have mostly no effect on desktop responsiveness, but if the desktop is left unattended for some time, there may be an initial lag while interacting with the desktop. This may be due to the kernel deciding that the system is idle enough to give a higher priority to the operation, and its data may end up filling the cache completely, dropping the pages from desktop applications.



            Regarding the disk scheduler, I have not done enough testing to know which would be the best option, but from my research, it seems that either deadline completely ignores ionice, or that ionice is specific to CFQ.






            share|improve this answer






























              0














              Apparently, the biggest issue was a swap problem. In my old system, setting vm.swappiness=100 helped me avoiding system freezes by moving pages before the memory was exhausted. On this new system, it seems to have had the opposite effect: the system was always constantly and needlessly swapping. I have purchased more RAM and totally disabled swap, and the problem was mostly solved.



              Regarding the fact that I/O operations caused desktop freezes, it seems to be because the data from the operation was being cached on RAM, and the memory used by desktop applications being thrown into the swap, which caused the system to read back from disk whenever I tried interacting with the desktop.



              With enough RAM, I/O operations have mostly no effect on desktop responsiveness, but if the desktop is left unattended for some time, there may be an initial lag while interacting with the desktop. This may be due to the kernel deciding that the system is idle enough to give a higher priority to the operation, and its data may end up filling the cache completely, dropping the pages from desktop applications.



              Regarding the disk scheduler, I have not done enough testing to know which would be the best option, but from my research, it seems that either deadline completely ignores ionice, or that ionice is specific to CFQ.






              share|improve this answer




























                0












                0








                0







                Apparently, the biggest issue was a swap problem. In my old system, setting vm.swappiness=100 helped me avoiding system freezes by moving pages before the memory was exhausted. On this new system, it seems to have had the opposite effect: the system was always constantly and needlessly swapping. I have purchased more RAM and totally disabled swap, and the problem was mostly solved.



                Regarding the fact that I/O operations caused desktop freezes, it seems to be because the data from the operation was being cached on RAM, and the memory used by desktop applications being thrown into the swap, which caused the system to read back from disk whenever I tried interacting with the desktop.



                With enough RAM, I/O operations have mostly no effect on desktop responsiveness, but if the desktop is left unattended for some time, there may be an initial lag while interacting with the desktop. This may be due to the kernel deciding that the system is idle enough to give a higher priority to the operation, and its data may end up filling the cache completely, dropping the pages from desktop applications.



                Regarding the disk scheduler, I have not done enough testing to know which would be the best option, but from my research, it seems that either deadline completely ignores ionice, or that ionice is specific to CFQ.






                share|improve this answer















                Apparently, the biggest issue was a swap problem. In my old system, setting vm.swappiness=100 helped me avoiding system freezes by moving pages before the memory was exhausted. On this new system, it seems to have had the opposite effect: the system was always constantly and needlessly swapping. I have purchased more RAM and totally disabled swap, and the problem was mostly solved.



                Regarding the fact that I/O operations caused desktop freezes, it seems to be because the data from the operation was being cached on RAM, and the memory used by desktop applications being thrown into the swap, which caused the system to read back from disk whenever I tried interacting with the desktop.



                With enough RAM, I/O operations have mostly no effect on desktop responsiveness, but if the desktop is left unattended for some time, there may be an initial lag while interacting with the desktop. This may be due to the kernel deciding that the system is idle enough to give a higher priority to the operation, and its data may end up filling the cache completely, dropping the pages from desktop applications.



                Regarding the disk scheduler, I have not done enough testing to know which would be the best option, but from my research, it seems that either deadline completely ignores ionice, or that ionice is specific to CFQ.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Mar 3 '16 at 14:43

























                answered Mar 3 '16 at 14:37









                Teresa e JuniorTeresa e Junior

                2,45753050




                2,45753050






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f265756%2fdesktop-completely-freezing-on-i-o-operations%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Accessing regular linux commands in Huawei's Dopra Linux

                    Can't connect RFCOMM socket: Host is down

                    Kernel panic - not syncing: Fatal Exception in Interrupt