Excessively high disk usage freezes my server
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
asked Jul 17 '14 at 15:44
Nicolas BoulianeNicolas Bouliane
1215
bumped to the homepage by Community♦ 2 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
|
show 1 more comment
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
asked Jul 17 '14 at 15:44
Nicolas BoulianeNicolas Bouliane
1215
bumped to the homepage by Community♦ 2 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 ofgrep 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 runtopand 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 commandvmstat 1. You can leave running in background and paste the most recent lines when it fails?
– LatinSuD
Jul 17 '14 at 17:43
|
show 1 more comment
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
asked Jul 17 '14 at 15:44
Nicolas BoulianeNicolas Bouliane
1215
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
linux linux-mint
asked Jul 17 '14 at 15:44
Nicolas BoulianeNicolas Bouliane
1215
asked Jul 17 '14 at 15:44
Nicolas BoulianeNicolas Bouliane
1215
edited Jul 18 '14 at 0:46
Nicolas Bouliane
asked Jul 17 '14 at 15:44
Nicolas BoulianeNicolas Bouliane
1215
asked Jul 17 '14 at 15:44
Nicolas BoulianeNicolas Bouliane
1215
asked Jul 17 '14 at 15:44
Nicolas BoulianeNicolas Bouliane
1215
1215
bumped to the homepage by Community♦ 2 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♦ 2 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 ofgrep 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 runtopand 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 commandvmstat 1. You can leave running in background and paste the most recent lines when it fails?
– LatinSuD
Jul 17 '14 at 17:43
|
show 1 more comment
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 ofgrep 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 runtopand 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 commandvmstat 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
|
show 1 more comment
1 Answer
1
active
oldest
votes
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
edited Apr 13 '17 at 12:36
Community♦
1
answered Jul 18 '14 at 0:18
strkIVstrkIV
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
|
show 2 more comments
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
edited Apr 13 '17 at 12:36
Community♦
1
answered Jul 18 '14 at 0:18
strkIVstrkIV
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
|
show 2 more comments
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
edited Apr 13 '17 at 12:36
Community♦
1
answered Jul 18 '14 at 0:18
strkIVstrkIV
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
|
show 2 more comments
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
edited Apr 13 '17 at 12:36
Community♦
1
answered Jul 18 '14 at 0:18
strkIVstrkIV
416
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
edited Apr 13 '17 at 12:36
Community♦
1
answered Jul 18 '14 at 0:18
strkIVstrkIV
416
edited Apr 13 '17 at 12:36
Community♦
1
edited Apr 13 '17 at 12:36
Community♦
1
edited Apr 13 '17 at 12:36
Community♦
1
1
answered Jul 18 '14 at 0:18
strkIVstrkIV
416
answered Jul 18 '14 at 0:18
strkIVstrkIV
416
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
|
show 2 more comments
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
|
show 2 more comments
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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
topand 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