Excessively high disk usage freezes my server












1















I have a laptop converted to a Linux Mint server running a variety of services. Recently, it started being unaccessible at random.



The situation seems intermittent. The server is usually blazing fast. I can still ping the server, but any attempt to access its services (ssh, web, etc) takes a prohibitive amount of time.



When I try to access the server with SSH, it can take over 15 minutes before I get to the login screen. The hard drive activity light stays on and the machine is running hotter than usual but not dangerously so. If I reboot the machine, it is super fast for some time, until it randomly becomes unresponsive again, maybe days later.



I have tried using iotop, but I've spent the past 45 minutes just waiting for it:



user@machine~ $ sudo iotop
[sudo] password for user: debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE

debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0


EDIT I power cycled the server and took a look at all the logs. These were the last entries in syslog. There were several hundred of identical lines preceding it:



Jul 17 20:35:16 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:35:40 pulseaudio[2106]: last message repeated 673 times
Jul 17 20:35:40 t510-mint rsyslogd-2177: imuxsock begins to drop messages from pid 2106 due to rate-limiting
Jul 17 20:35:41 t510-mint rsyslogd-2177: imuxsock lost 6 messages from pid 2106 due to rate-limiting
Jul 17 20:35:41 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:36:05 pulseaudio[2106]: last message repeated 673 times
Jul 17 20:36:05 t510-mint rsyslogd-2177: imuxsock begins to drop messages from pid 2106 due to rate-limiting
Jul 17 20:36:06 t510-mint rsyslogd-2177: imuxsock lost 6 messages from pid 2106 due to rate-limiting
Jul 17 20:36:06 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:37:19 pulseaudio[2106]: last message repeated 567 times









share|improve this question
















bumped to the homepage by Community 29 mins ago


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
















  • Logs? Did you check logs? like /var/log/messages or /var/log/dmesg.0 and so on?

    – rush
    Jul 17 '14 at 15:48






  • 1





    Sounds like a swapping issue. Please edit your question and tell us how much RAM and how much swap you have. Also show us the output of grep swappiness /etc/sysctl.conf.

    – terdon
    Jul 17 '14 at 15:48











  • I would love to check the logs, but the system is still inaccessible. The swappiness settings should be the default ones. However, I have considered checking for memory usage too.

    – Nicolas Bouliane
    Jul 17 '14 at 15:59











  • Also run top and look at the VIRT column to see if there's anything that is a lot larger than the size of your RAM.

    – Mark Plotnick
    Jul 17 '14 at 16:13











  • I like this command vmstat 1. You can leave running in background and paste the most recent lines when it fails?

    – LatinSuD
    Jul 17 '14 at 17:43
















1















I have a laptop converted to a Linux Mint server running a variety of services. Recently, it started being unaccessible at random.



The situation seems intermittent. The server is usually blazing fast. I can still ping the server, but any attempt to access its services (ssh, web, etc) takes a prohibitive amount of time.



When I try to access the server with SSH, it can take over 15 minutes before I get to the login screen. The hard drive activity light stays on and the machine is running hotter than usual but not dangerously so. If I reboot the machine, it is super fast for some time, until it randomly becomes unresponsive again, maybe days later.



I have tried using iotop, but I've spent the past 45 minutes just waiting for it:



user@machine~ $ sudo iotop
[sudo] password for user: debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE

debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0


EDIT I power cycled the server and took a look at all the logs. These were the last entries in syslog. There were several hundred of identical lines preceding it:



Jul 17 20:35:16 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:35:40 pulseaudio[2106]: last message repeated 673 times
Jul 17 20:35:40 t510-mint rsyslogd-2177: imuxsock begins to drop messages from pid 2106 due to rate-limiting
Jul 17 20:35:41 t510-mint rsyslogd-2177: imuxsock lost 6 messages from pid 2106 due to rate-limiting
Jul 17 20:35:41 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:36:05 pulseaudio[2106]: last message repeated 673 times
Jul 17 20:36:05 t510-mint rsyslogd-2177: imuxsock begins to drop messages from pid 2106 due to rate-limiting
Jul 17 20:36:06 t510-mint rsyslogd-2177: imuxsock lost 6 messages from pid 2106 due to rate-limiting
Jul 17 20:36:06 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:37:19 pulseaudio[2106]: last message repeated 567 times









share|improve this question
















bumped to the homepage by Community 29 mins ago


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
















  • Logs? Did you check logs? like /var/log/messages or /var/log/dmesg.0 and so on?

    – rush
    Jul 17 '14 at 15:48






  • 1





    Sounds like a swapping issue. Please edit your question and tell us how much RAM and how much swap you have. Also show us the output of grep swappiness /etc/sysctl.conf.

    – terdon
    Jul 17 '14 at 15:48











  • I would love to check the logs, but the system is still inaccessible. The swappiness settings should be the default ones. However, I have considered checking for memory usage too.

    – Nicolas Bouliane
    Jul 17 '14 at 15:59











  • Also run top and look at the VIRT column to see if there's anything that is a lot larger than the size of your RAM.

    – Mark Plotnick
    Jul 17 '14 at 16:13











  • I like this command vmstat 1. You can leave running in background and paste the most recent lines when it fails?

    – LatinSuD
    Jul 17 '14 at 17:43














1












1








1








I have a laptop converted to a Linux Mint server running a variety of services. Recently, it started being unaccessible at random.



The situation seems intermittent. The server is usually blazing fast. I can still ping the server, but any attempt to access its services (ssh, web, etc) takes a prohibitive amount of time.



When I try to access the server with SSH, it can take over 15 minutes before I get to the login screen. The hard drive activity light stays on and the machine is running hotter than usual but not dangerously so. If I reboot the machine, it is super fast for some time, until it randomly becomes unresponsive again, maybe days later.



I have tried using iotop, but I've spent the past 45 minutes just waiting for it:



user@machine~ $ sudo iotop
[sudo] password for user: debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE

debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0


EDIT I power cycled the server and took a look at all the logs. These were the last entries in syslog. There were several hundred of identical lines preceding it:



Jul 17 20:35:16 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:35:40 pulseaudio[2106]: last message repeated 673 times
Jul 17 20:35:40 t510-mint rsyslogd-2177: imuxsock begins to drop messages from pid 2106 due to rate-limiting
Jul 17 20:35:41 t510-mint rsyslogd-2177: imuxsock lost 6 messages from pid 2106 due to rate-limiting
Jul 17 20:35:41 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:36:05 pulseaudio[2106]: last message repeated 673 times
Jul 17 20:36:05 t510-mint rsyslogd-2177: imuxsock begins to drop messages from pid 2106 due to rate-limiting
Jul 17 20:36:06 t510-mint rsyslogd-2177: imuxsock lost 6 messages from pid 2106 due to rate-limiting
Jul 17 20:36:06 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:37:19 pulseaudio[2106]: last message repeated 567 times









share|improve this question
















I have a laptop converted to a Linux Mint server running a variety of services. Recently, it started being unaccessible at random.



The situation seems intermittent. The server is usually blazing fast. I can still ping the server, but any attempt to access its services (ssh, web, etc) takes a prohibitive amount of time.



When I try to access the server with SSH, it can take over 15 minutes before I get to the login screen. The hard drive activity light stays on and the machine is running hotter than usual but not dangerously so. If I reboot the machine, it is super fast for some time, until it randomly becomes unresponsive again, maybe days later.



I have tried using iotop, but I've spent the past 45 minutes just waiting for it:



user@machine~ $ sudo iotop
[sudo] password for user: debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE
debug3: Received SSH2_MSG_IGNORE

debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0


EDIT I power cycled the server and took a look at all the logs. These were the last entries in syslog. There were several hundred of identical lines preceding it:



Jul 17 20:35:16 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:35:40 pulseaudio[2106]: last message repeated 673 times
Jul 17 20:35:40 t510-mint rsyslogd-2177: imuxsock begins to drop messages from pid 2106 due to rate-limiting
Jul 17 20:35:41 t510-mint rsyslogd-2177: imuxsock lost 6 messages from pid 2106 due to rate-limiting
Jul 17 20:35:41 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:36:05 pulseaudio[2106]: last message repeated 673 times
Jul 17 20:36:05 t510-mint rsyslogd-2177: imuxsock begins to drop messages from pid 2106 due to rate-limiting
Jul 17 20:36:06 t510-mint rsyslogd-2177: imuxsock lost 6 messages from pid 2106 due to rate-limiting
Jul 17 20:36:06 t510-mint pulseaudio[2106]: [pulseaudio] protocol-native.c: Warning! Too many connections (64), dropping incoming connection.
Jul 17 20:37:19 pulseaudio[2106]: last message repeated 567 times






linux linux-mint






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 18 '14 at 0:46







Nicolas Bouliane

















asked Jul 17 '14 at 15:44









Nicolas BoulianeNicolas Bouliane

1215




1215





bumped to the homepage by Community 29 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 29 mins ago


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















  • Logs? Did you check logs? like /var/log/messages or /var/log/dmesg.0 and so on?

    – rush
    Jul 17 '14 at 15:48






  • 1





    Sounds like a swapping issue. Please edit your question and tell us how much RAM and how much swap you have. Also show us the output of grep swappiness /etc/sysctl.conf.

    – terdon
    Jul 17 '14 at 15:48











  • I would love to check the logs, but the system is still inaccessible. The swappiness settings should be the default ones. However, I have considered checking for memory usage too.

    – Nicolas Bouliane
    Jul 17 '14 at 15:59











  • Also run top and look at the VIRT column to see if there's anything that is a lot larger than the size of your RAM.

    – Mark Plotnick
    Jul 17 '14 at 16:13











  • I like this command vmstat 1. You can leave running in background and paste the most recent lines when it fails?

    – LatinSuD
    Jul 17 '14 at 17:43



















  • Logs? Did you check logs? like /var/log/messages or /var/log/dmesg.0 and so on?

    – rush
    Jul 17 '14 at 15:48






  • 1





    Sounds like a swapping issue. Please edit your question and tell us how much RAM and how much swap you have. Also show us the output of grep swappiness /etc/sysctl.conf.

    – terdon
    Jul 17 '14 at 15:48











  • I would love to check the logs, but the system is still inaccessible. The swappiness settings should be the default ones. However, I have considered checking for memory usage too.

    – Nicolas Bouliane
    Jul 17 '14 at 15:59











  • Also run top and look at the VIRT column to see if there's anything that is a lot larger than the size of your RAM.

    – Mark Plotnick
    Jul 17 '14 at 16:13











  • I like this command vmstat 1. You can leave running in background and paste the most recent lines when it fails?

    – LatinSuD
    Jul 17 '14 at 17:43

















Logs? Did you check logs? like /var/log/messages or /var/log/dmesg.0 and so on?

– rush
Jul 17 '14 at 15:48





Logs? Did you check logs? like /var/log/messages or /var/log/dmesg.0 and so on?

– rush
Jul 17 '14 at 15:48




1




1





Sounds like a swapping issue. Please edit your question and tell us how much RAM and how much swap you have. Also show us the output of grep swappiness /etc/sysctl.conf.

– terdon
Jul 17 '14 at 15:48





Sounds like a swapping issue. Please edit your question and tell us how much RAM and how much swap you have. Also show us the output of grep swappiness /etc/sysctl.conf.

– terdon
Jul 17 '14 at 15:48













I would love to check the logs, but the system is still inaccessible. The swappiness settings should be the default ones. However, I have considered checking for memory usage too.

– Nicolas Bouliane
Jul 17 '14 at 15:59





I would love to check the logs, but the system is still inaccessible. The swappiness settings should be the default ones. However, I have considered checking for memory usage too.

– Nicolas Bouliane
Jul 17 '14 at 15:59













Also run top and look at the VIRT column to see if there's anything that is a lot larger than the size of your RAM.

– Mark Plotnick
Jul 17 '14 at 16:13





Also run top and look at the VIRT column to see if there's anything that is a lot larger than the size of your RAM.

– Mark Plotnick
Jul 17 '14 at 16:13













I like this command vmstat 1. You can leave running in background and paste the most recent lines when it fails?

– LatinSuD
Jul 17 '14 at 17:43





I like this command vmstat 1. You can leave running in background and paste the most recent lines when it fails?

– LatinSuD
Jul 17 '14 at 17:43










1 Answer
1






active

oldest

votes


















0














You can try accessing the system in runlevel 3 for multiuser command line mode and try to clean some space on the / filesystem, while you are at it, it'll be a great idea to get some unused space (if any) for some extra swap. If you already are in runlevel 3, then clean the system at runlevel 1 which will load basic services for you to run diagnostics and/or troubleshoot. The system should become accessible from this runlevel and you should be able to get some logs as well (grep swappiness /etc/sysctl.conf).



Take a look at this post for runlevel info:



Debian init runlevels






share|improve this answer


























  • The filesystem has plenty of space left, so that is not an issue. The grep command returns nothing with those parameters.

    – Nicolas Bouliane
    Jul 18 '14 at 0:22











  • What about the swap space? Do you have enough assigned? grep SwapTotal /proc/meminfo

    – strkIV
    Jul 18 '14 at 0:38













  • I was able to get the same thing to happen a few seconds ago. There was plenty of RAM left, so it shouldn't be a problem, correct?

    – Nicolas Bouliane
    Jul 18 '14 at 0:40











  • Well, enough RAM doesn't always means that you are OK to go. RAM is always important, but Linux uses swap space too for process buffering. Swap is recommended to be 2x the size of RAM but this is just a suggestion. If you have enough RAM and HDD space, then 1x of swap should be OK. Something else to check is what the top command gives you when the services are running, try: top > Shift+f > n. That will give you who's eating RAM when the problem occurs

    – strkIV
    Jul 18 '14 at 0:46













  • Got 8GB of SWAP (and 4GB of RAM), so I assume this is fine?

    – Nicolas Bouliane
    Jul 18 '14 at 0:49











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%2f145128%2fexcessively-high-disk-usage-freezes-my-server%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














You can try accessing the system in runlevel 3 for multiuser command line mode and try to clean some space on the / filesystem, while you are at it, it'll be a great idea to get some unused space (if any) for some extra swap. If you already are in runlevel 3, then clean the system at runlevel 1 which will load basic services for you to run diagnostics and/or troubleshoot. The system should become accessible from this runlevel and you should be able to get some logs as well (grep swappiness /etc/sysctl.conf).



Take a look at this post for runlevel info:



Debian init runlevels






share|improve this answer


























  • The filesystem has plenty of space left, so that is not an issue. The grep command returns nothing with those parameters.

    – Nicolas Bouliane
    Jul 18 '14 at 0:22











  • What about the swap space? Do you have enough assigned? grep SwapTotal /proc/meminfo

    – strkIV
    Jul 18 '14 at 0:38













  • I was able to get the same thing to happen a few seconds ago. There was plenty of RAM left, so it shouldn't be a problem, correct?

    – Nicolas Bouliane
    Jul 18 '14 at 0:40











  • Well, enough RAM doesn't always means that you are OK to go. RAM is always important, but Linux uses swap space too for process buffering. Swap is recommended to be 2x the size of RAM but this is just a suggestion. If you have enough RAM and HDD space, then 1x of swap should be OK. Something else to check is what the top command gives you when the services are running, try: top > Shift+f > n. That will give you who's eating RAM when the problem occurs

    – strkIV
    Jul 18 '14 at 0:46













  • Got 8GB of SWAP (and 4GB of RAM), so I assume this is fine?

    – Nicolas Bouliane
    Jul 18 '14 at 0:49
















0














You can try accessing the system in runlevel 3 for multiuser command line mode and try to clean some space on the / filesystem, while you are at it, it'll be a great idea to get some unused space (if any) for some extra swap. If you already are in runlevel 3, then clean the system at runlevel 1 which will load basic services for you to run diagnostics and/or troubleshoot. The system should become accessible from this runlevel and you should be able to get some logs as well (grep swappiness /etc/sysctl.conf).



Take a look at this post for runlevel info:



Debian init runlevels






share|improve this answer


























  • The filesystem has plenty of space left, so that is not an issue. The grep command returns nothing with those parameters.

    – Nicolas Bouliane
    Jul 18 '14 at 0:22











  • What about the swap space? Do you have enough assigned? grep SwapTotal /proc/meminfo

    – strkIV
    Jul 18 '14 at 0:38













  • I was able to get the same thing to happen a few seconds ago. There was plenty of RAM left, so it shouldn't be a problem, correct?

    – Nicolas Bouliane
    Jul 18 '14 at 0:40











  • Well, enough RAM doesn't always means that you are OK to go. RAM is always important, but Linux uses swap space too for process buffering. Swap is recommended to be 2x the size of RAM but this is just a suggestion. If you have enough RAM and HDD space, then 1x of swap should be OK. Something else to check is what the top command gives you when the services are running, try: top > Shift+f > n. That will give you who's eating RAM when the problem occurs

    – strkIV
    Jul 18 '14 at 0:46













  • Got 8GB of SWAP (and 4GB of RAM), so I assume this is fine?

    – Nicolas Bouliane
    Jul 18 '14 at 0:49














0












0








0







You can try accessing the system in runlevel 3 for multiuser command line mode and try to clean some space on the / filesystem, while you are at it, it'll be a great idea to get some unused space (if any) for some extra swap. If you already are in runlevel 3, then clean the system at runlevel 1 which will load basic services for you to run diagnostics and/or troubleshoot. The system should become accessible from this runlevel and you should be able to get some logs as well (grep swappiness /etc/sysctl.conf).



Take a look at this post for runlevel info:



Debian init runlevels






share|improve this answer















You can try accessing the system in runlevel 3 for multiuser command line mode and try to clean some space on the / filesystem, while you are at it, it'll be a great idea to get some unused space (if any) for some extra swap. If you already are in runlevel 3, then clean the system at runlevel 1 which will load basic services for you to run diagnostics and/or troubleshoot. The system should become accessible from this runlevel and you should be able to get some logs as well (grep swappiness /etc/sysctl.conf).



Take a look at this post for runlevel info:



Debian init runlevels







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 13 '17 at 12:36









Community

1




1










answered Jul 18 '14 at 0:18









strkIVstrkIV

416




416













  • The filesystem has plenty of space left, so that is not an issue. The grep command returns nothing with those parameters.

    – Nicolas Bouliane
    Jul 18 '14 at 0:22











  • What about the swap space? Do you have enough assigned? grep SwapTotal /proc/meminfo

    – strkIV
    Jul 18 '14 at 0:38













  • I was able to get the same thing to happen a few seconds ago. There was plenty of RAM left, so it shouldn't be a problem, correct?

    – Nicolas Bouliane
    Jul 18 '14 at 0:40











  • Well, enough RAM doesn't always means that you are OK to go. RAM is always important, but Linux uses swap space too for process buffering. Swap is recommended to be 2x the size of RAM but this is just a suggestion. If you have enough RAM and HDD space, then 1x of swap should be OK. Something else to check is what the top command gives you when the services are running, try: top > Shift+f > n. That will give you who's eating RAM when the problem occurs

    – strkIV
    Jul 18 '14 at 0:46













  • Got 8GB of SWAP (and 4GB of RAM), so I assume this is fine?

    – Nicolas Bouliane
    Jul 18 '14 at 0:49



















  • The filesystem has plenty of space left, so that is not an issue. The grep command returns nothing with those parameters.

    – Nicolas Bouliane
    Jul 18 '14 at 0:22











  • What about the swap space? Do you have enough assigned? grep SwapTotal /proc/meminfo

    – strkIV
    Jul 18 '14 at 0:38













  • I was able to get the same thing to happen a few seconds ago. There was plenty of RAM left, so it shouldn't be a problem, correct?

    – Nicolas Bouliane
    Jul 18 '14 at 0:40











  • Well, enough RAM doesn't always means that you are OK to go. RAM is always important, but Linux uses swap space too for process buffering. Swap is recommended to be 2x the size of RAM but this is just a suggestion. If you have enough RAM and HDD space, then 1x of swap should be OK. Something else to check is what the top command gives you when the services are running, try: top > Shift+f > n. That will give you who's eating RAM when the problem occurs

    – strkIV
    Jul 18 '14 at 0:46













  • Got 8GB of SWAP (and 4GB of RAM), so I assume this is fine?

    – Nicolas Bouliane
    Jul 18 '14 at 0:49

















The filesystem has plenty of space left, so that is not an issue. The grep command returns nothing with those parameters.

– Nicolas Bouliane
Jul 18 '14 at 0:22





The filesystem has plenty of space left, so that is not an issue. The grep command returns nothing with those parameters.

– Nicolas Bouliane
Jul 18 '14 at 0:22













What about the swap space? Do you have enough assigned? grep SwapTotal /proc/meminfo

– strkIV
Jul 18 '14 at 0:38







What about the swap space? Do you have enough assigned? grep SwapTotal /proc/meminfo

– strkIV
Jul 18 '14 at 0:38















I was able to get the same thing to happen a few seconds ago. There was plenty of RAM left, so it shouldn't be a problem, correct?

– Nicolas Bouliane
Jul 18 '14 at 0:40





I was able to get the same thing to happen a few seconds ago. There was plenty of RAM left, so it shouldn't be a problem, correct?

– Nicolas Bouliane
Jul 18 '14 at 0:40













Well, enough RAM doesn't always means that you are OK to go. RAM is always important, but Linux uses swap space too for process buffering. Swap is recommended to be 2x the size of RAM but this is just a suggestion. If you have enough RAM and HDD space, then 1x of swap should be OK. Something else to check is what the top command gives you when the services are running, try: top > Shift+f > n. That will give you who's eating RAM when the problem occurs

– strkIV
Jul 18 '14 at 0:46







Well, enough RAM doesn't always means that you are OK to go. RAM is always important, but Linux uses swap space too for process buffering. Swap is recommended to be 2x the size of RAM but this is just a suggestion. If you have enough RAM and HDD space, then 1x of swap should be OK. Something else to check is what the top command gives you when the services are running, try: top > Shift+f > n. That will give you who's eating RAM when the problem occurs

– strkIV
Jul 18 '14 at 0:46















Got 8GB of SWAP (and 4GB of RAM), so I assume this is fine?

– Nicolas Bouliane
Jul 18 '14 at 0:49





Got 8GB of SWAP (and 4GB of RAM), so I assume this is fine?

– Nicolas Bouliane
Jul 18 '14 at 0:49


















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%2f145128%2fexcessively-high-disk-usage-freezes-my-server%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