Ubuntu freeze when low memory
Clash Royale CLAN TAG#URR8PPP up vote
4
down vote
favorite
My ubuntu server worked for one month without any problem. But last week I had started to use programs that require more memory. And when free memory is around 100MB, system completelly freeze. I cant type anything, move cursor, connect from putty.. simply nothing.. but strange is, that hard drive is still working(is blinking).. I can fully reproduce this problem and it occurs almost every time when free memory is around 100MB. But I have swap file, and in this swap file is enough free space.. Here is my memory status 1 second before it freezed.
Every 1.0s free -mh Mon Mar 19 17:05:33 2018
total used free shared buff/cache available
Mem: 11G 10G 115M 1.2G 1.5G 115M
Swap: 7.9G 2.4G 5.5G
Here is my linux kernel
Linux xxx 4.15.1-041501-generic #201802031831 SMP Sat Feb 3 18:32:13 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Here is my ubuntu version
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 17.10
Release: 17.10
Codename: artful
Here is my swappines, overcommit_memory and overcommit_ratio configuration
vm.swappiness = 60
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
Here is my hardware configuration
Motherboard: PRIME B350-PLUS
CPU : AMD Ryzen 7 1700 Eight-Core Processor
RAM : 4GB + 8GB DDR4
Hard drive : Samsung 960 evo 250GB
Of course, I can upgrade my memory to 16GB, but still i want to have my system stable. Does anyone have some idea what could be wrong?
ram freeze swap
asked Mar 21 at 9:26
user1247373
211
 |Â
show 1 more comment
up vote
4
down vote
favorite
My ubuntu server worked for one month without any problem. But last week I had started to use programs that require more memory. And when free memory is around 100MB, system completelly freeze. I cant type anything, move cursor, connect from putty.. simply nothing.. but strange is, that hard drive is still working(is blinking).. I can fully reproduce this problem and it occurs almost every time when free memory is around 100MB. But I have swap file, and in this swap file is enough free space.. Here is my memory status 1 second before it freezed.
Every 1.0s free -mh Mon Mar 19 17:05:33 2018
total used free shared buff/cache available
Mem: 11G 10G 115M 1.2G 1.5G 115M
Swap: 7.9G 2.4G 5.5G
Here is my linux kernel
Linux xxx 4.15.1-041501-generic #201802031831 SMP Sat Feb 3 18:32:13 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Here is my ubuntu version
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 17.10
Release: 17.10
Codename: artful
Here is my swappines, overcommit_memory and overcommit_ratio configuration
vm.swappiness = 60
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
Here is my hardware configuration
Motherboard: PRIME B350-PLUS
CPU : AMD Ryzen 7 1700 Eight-Core Processor
RAM : 4GB + 8GB DDR4
Hard drive : Samsung 960 evo 250GB
Of course, I can upgrade my memory to 16GB, but still i want to have my system stable. Does anyone have some idea what could be wrong?
ram freeze swap
asked Mar 21 at 9:26
user1247373
211
Nothing's wrong. When a system runs out of memory, it'll fall back to using the swapfile which can grind the OS to a halt. There isn't a way to use a lot of swap and maintain system responsiveness because permanent storage devices are slow by nature.
– dsstorefile1
Mar 21 at 9:30
Can you include the output from:cat /proc/cmdline? Also4.15.1is old. The newest is4.15.11: kernel.ubuntu.com/~kernel-ppa/mainline/v4.15.11
– WinEunuuchs2Unix
Mar 21 at 10:56
1
I'm seeing this issue too, and I'm interested why this didn't happen in Ubuntu < 17.10. Let me reinforce: I've never seen my system freeze due to exhaustion of RAM (for years). - I've noticed that GNOME Shell seems to use significantly more RAM than Unity used to, but that very problem shouldn't be tied to the desktop, should it?
– Peterino
Mar 27 at 9:16
1
Another case here. @dsstorefile: in my case (and I guess other users too) the system doesn't grind to a halt but often rather just stops completely with no warning.
– Erik I
Apr 23 at 2:12
1
Same happens here as well. An unresponsive system due to swapping is one thing, but here the system goes from "everything is fine" to "I can't even move my mouse anymore" within a second. I am pretty sure this is not intended behavior.
– Plankalkül
Jul 21 at 14:59
 |Â
show 1 more comment
up vote
4
down vote
favorite
up vote
4
down vote
favorite
My ubuntu server worked for one month without any problem. But last week I had started to use programs that require more memory. And when free memory is around 100MB, system completelly freeze. I cant type anything, move cursor, connect from putty.. simply nothing.. but strange is, that hard drive is still working(is blinking).. I can fully reproduce this problem and it occurs almost every time when free memory is around 100MB. But I have swap file, and in this swap file is enough free space.. Here is my memory status 1 second before it freezed.
Every 1.0s free -mh Mon Mar 19 17:05:33 2018
total used free shared buff/cache available
Mem: 11G 10G 115M 1.2G 1.5G 115M
Swap: 7.9G 2.4G 5.5G
Here is my linux kernel
Linux xxx 4.15.1-041501-generic #201802031831 SMP Sat Feb 3 18:32:13 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Here is my ubuntu version
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 17.10
Release: 17.10
Codename: artful
Here is my swappines, overcommit_memory and overcommit_ratio configuration
vm.swappiness = 60
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
Here is my hardware configuration
Motherboard: PRIME B350-PLUS
CPU : AMD Ryzen 7 1700 Eight-Core Processor
RAM : 4GB + 8GB DDR4
Hard drive : Samsung 960 evo 250GB
Of course, I can upgrade my memory to 16GB, but still i want to have my system stable. Does anyone have some idea what could be wrong?
ram freeze swap
asked Mar 21 at 9:26
user1247373
211
My ubuntu server worked for one month without any problem. But last week I had started to use programs that require more memory. And when free memory is around 100MB, system completelly freeze. I cant type anything, move cursor, connect from putty.. simply nothing.. but strange is, that hard drive is still working(is blinking).. I can fully reproduce this problem and it occurs almost every time when free memory is around 100MB. But I have swap file, and in this swap file is enough free space.. Here is my memory status 1 second before it freezed.
Every 1.0s free -mh Mon Mar 19 17:05:33 2018
total used free shared buff/cache available
Mem: 11G 10G 115M 1.2G 1.5G 115M
Swap: 7.9G 2.4G 5.5G
Here is my linux kernel
Linux xxx 4.15.1-041501-generic #201802031831 SMP Sat Feb 3 18:32:13 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Here is my ubuntu version
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 17.10
Release: 17.10
Codename: artful
Here is my swappines, overcommit_memory and overcommit_ratio configuration
vm.swappiness = 60
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
Here is my hardware configuration
Motherboard: PRIME B350-PLUS
CPU : AMD Ryzen 7 1700 Eight-Core Processor
RAM : 4GB + 8GB DDR4
Hard drive : Samsung 960 evo 250GB
Of course, I can upgrade my memory to 16GB, but still i want to have my system stable. Does anyone have some idea what could be wrong?
ram freeze swap
ram freeze swap
asked Mar 21 at 9:26
user1247373
211
asked Mar 21 at 9:26
user1247373
211
asked Mar 21 at 9:26
user1247373
211
asked Mar 21 at 9:26
user1247373
211
asked Mar 21 at 9:26
user1247373
211
211
Nothing's wrong. When a system runs out of memory, it'll fall back to using the swapfile which can grind the OS to a halt. There isn't a way to use a lot of swap and maintain system responsiveness because permanent storage devices are slow by nature.
– dsstorefile1
Mar 21 at 9:30
Can you include the output from:cat /proc/cmdline? Also4.15.1is old. The newest is4.15.11: kernel.ubuntu.com/~kernel-ppa/mainline/v4.15.11
– WinEunuuchs2Unix
Mar 21 at 10:56
1
I'm seeing this issue too, and I'm interested why this didn't happen in Ubuntu < 17.10. Let me reinforce: I've never seen my system freeze due to exhaustion of RAM (for years). - I've noticed that GNOME Shell seems to use significantly more RAM than Unity used to, but that very problem shouldn't be tied to the desktop, should it?
– Peterino
Mar 27 at 9:16
1
Another case here. @dsstorefile: in my case (and I guess other users too) the system doesn't grind to a halt but often rather just stops completely with no warning.
– Erik I
Apr 23 at 2:12
1
Same happens here as well. An unresponsive system due to swapping is one thing, but here the system goes from "everything is fine" to "I can't even move my mouse anymore" within a second. I am pretty sure this is not intended behavior.
– Plankalkül
Jul 21 at 14:59
 |Â
show 1 more comment
Nothing's wrong. When a system runs out of memory, it'll fall back to using the swapfile which can grind the OS to a halt. There isn't a way to use a lot of swap and maintain system responsiveness because permanent storage devices are slow by nature.
– dsstorefile1
Mar 21 at 9:30
Can you include the output from:cat /proc/cmdline? Also4.15.1is old. The newest is4.15.11: kernel.ubuntu.com/~kernel-ppa/mainline/v4.15.11
– WinEunuuchs2Unix
Mar 21 at 10:56
1
I'm seeing this issue too, and I'm interested why this didn't happen in Ubuntu < 17.10. Let me reinforce: I've never seen my system freeze due to exhaustion of RAM (for years). - I've noticed that GNOME Shell seems to use significantly more RAM than Unity used to, but that very problem shouldn't be tied to the desktop, should it?
– Peterino
Mar 27 at 9:16
1
Another case here. @dsstorefile: in my case (and I guess other users too) the system doesn't grind to a halt but often rather just stops completely with no warning.
– Erik I
Apr 23 at 2:12
1
Same happens here as well. An unresponsive system due to swapping is one thing, but here the system goes from "everything is fine" to "I can't even move my mouse anymore" within a second. I am pretty sure this is not intended behavior.
– Plankalkül
Jul 21 at 14:59
Nothing's wrong. When a system runs out of memory, it'll fall back to using the swapfile which can grind the OS to a halt. There isn't a way to use a lot of swap and maintain system responsiveness because permanent storage devices are slow by nature.
– dsstorefile1
Mar 21 at 9:30
Nothing's wrong. When a system runs out of memory, it'll fall back to using the swapfile which can grind the OS to a halt. There isn't a way to use a lot of swap and maintain system responsiveness because permanent storage devices are slow by nature.
– dsstorefile1
Mar 21 at 9:30
Can you include the output from:
cat /proc/cmdline? Also 4.15.1 is old. The newest is 4.15.11: kernel.ubuntu.com/~kernel-ppa/mainline/v4.15.11– WinEunuuchs2Unix
Mar 21 at 10:56
Can you include the output from:
cat /proc/cmdline? Also 4.15.1 is old. The newest is 4.15.11: kernel.ubuntu.com/~kernel-ppa/mainline/v4.15.11– WinEunuuchs2Unix
Mar 21 at 10:56
1
1
I'm seeing this issue too, and I'm interested why this didn't happen in Ubuntu < 17.10. Let me reinforce: I've never seen my system freeze due to exhaustion of RAM (for years). - I've noticed that GNOME Shell seems to use significantly more RAM than Unity used to, but that very problem shouldn't be tied to the desktop, should it?
– Peterino
Mar 27 at 9:16
I'm seeing this issue too, and I'm interested why this didn't happen in Ubuntu < 17.10. Let me reinforce: I've never seen my system freeze due to exhaustion of RAM (for years). - I've noticed that GNOME Shell seems to use significantly more RAM than Unity used to, but that very problem shouldn't be tied to the desktop, should it?
– Peterino
Mar 27 at 9:16
1
1
Another case here. @dsstorefile: in my case (and I guess other users too) the system doesn't grind to a halt but often rather just stops completely with no warning.
– Erik I
Apr 23 at 2:12
Another case here. @dsstorefile: in my case (and I guess other users too) the system doesn't grind to a halt but often rather just stops completely with no warning.
– Erik I
Apr 23 at 2:12
1
1
Same happens here as well. An unresponsive system due to swapping is one thing, but here the system goes from "everything is fine" to "I can't even move my mouse anymore" within a second. I am pretty sure this is not intended behavior.
– Plankalkül
Jul 21 at 14:59
Same happens here as well. An unresponsive system due to swapping is one thing, but here the system goes from "everything is fine" to "I can't even move my mouse anymore" within a second. I am pretty sure this is not intended behavior.
– Plankalkül
Jul 21 at 14:59
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
1
down vote
I believe this is the same question as this one, even though you have swap enabled: https://unix.stackexchange.com/q/373312/306023
Basically the kernel (or kswapd0) is evicting every active process's code (executable) pages in order to free more RAM, thus on every context switch when a process resumes execution, it needs to be re-read from disk into memory and only then can it resume execution.
This needs to happen so many times per second, coupled with the fact that disk are way slower than RAM, that the OS is seen as effectively freezing up. It's as if RAM gets temporarily replaced by the disk, and all of this is because the kernel makes the mistake ofis evicting the running processes's file-backed executable pages too, instead of just the inactive ones.
If you want to try and see what happens if the kernel doesn't evict those, you can recompile the kernel with this patch, seen in this question. What should happen is that the OS should freeze for at most 1 second now instead of minutes(or permanently) and there should be little to no disk thrashing.
edited Aug 31 at 13:44
Thomas Ward♦
41.5k23112166
answered Aug 31 at 10:33
Marcus Linsner
113
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
I believe this is the same question as this one, even though you have swap enabled: https://unix.stackexchange.com/q/373312/306023
Basically the kernel (or kswapd0) is evicting every active process's code (executable) pages in order to free more RAM, thus on every context switch when a process resumes execution, it needs to be re-read from disk into memory and only then can it resume execution.
This needs to happen so many times per second, coupled with the fact that disk are way slower than RAM, that the OS is seen as effectively freezing up. It's as if RAM gets temporarily replaced by the disk, and all of this is because the kernel makes the mistake ofis evicting the running processes's file-backed executable pages too, instead of just the inactive ones.
If you want to try and see what happens if the kernel doesn't evict those, you can recompile the kernel with this patch, seen in this question. What should happen is that the OS should freeze for at most 1 second now instead of minutes(or permanently) and there should be little to no disk thrashing.
edited Aug 31 at 13:44
Thomas Ward♦
41.5k23112166
answered Aug 31 at 10:33
Marcus Linsner
113
add a comment |Â
up vote
1
down vote
I believe this is the same question as this one, even though you have swap enabled: https://unix.stackexchange.com/q/373312/306023
Basically the kernel (or kswapd0) is evicting every active process's code (executable) pages in order to free more RAM, thus on every context switch when a process resumes execution, it needs to be re-read from disk into memory and only then can it resume execution.
This needs to happen so many times per second, coupled with the fact that disk are way slower than RAM, that the OS is seen as effectively freezing up. It's as if RAM gets temporarily replaced by the disk, and all of this is because the kernel makes the mistake ofis evicting the running processes's file-backed executable pages too, instead of just the inactive ones.
If you want to try and see what happens if the kernel doesn't evict those, you can recompile the kernel with this patch, seen in this question. What should happen is that the OS should freeze for at most 1 second now instead of minutes(or permanently) and there should be little to no disk thrashing.
edited Aug 31 at 13:44
Thomas Ward♦
41.5k23112166
answered Aug 31 at 10:33
Marcus Linsner
113
add a comment |Â
up vote
1
down vote
up vote
1
down vote
I believe this is the same question as this one, even though you have swap enabled: https://unix.stackexchange.com/q/373312/306023
Basically the kernel (or kswapd0) is evicting every active process's code (executable) pages in order to free more RAM, thus on every context switch when a process resumes execution, it needs to be re-read from disk into memory and only then can it resume execution.
This needs to happen so many times per second, coupled with the fact that disk are way slower than RAM, that the OS is seen as effectively freezing up. It's as if RAM gets temporarily replaced by the disk, and all of this is because the kernel makes the mistake ofis evicting the running processes's file-backed executable pages too, instead of just the inactive ones.
If you want to try and see what happens if the kernel doesn't evict those, you can recompile the kernel with this patch, seen in this question. What should happen is that the OS should freeze for at most 1 second now instead of minutes(or permanently) and there should be little to no disk thrashing.
edited Aug 31 at 13:44
Thomas Ward♦
41.5k23112166
answered Aug 31 at 10:33
Marcus Linsner
113
I believe this is the same question as this one, even though you have swap enabled: https://unix.stackexchange.com/q/373312/306023
Basically the kernel (or kswapd0) is evicting every active process's code (executable) pages in order to free more RAM, thus on every context switch when a process resumes execution, it needs to be re-read from disk into memory and only then can it resume execution.
This needs to happen so many times per second, coupled with the fact that disk are way slower than RAM, that the OS is seen as effectively freezing up. It's as if RAM gets temporarily replaced by the disk, and all of this is because the kernel makes the mistake ofis evicting the running processes's file-backed executable pages too, instead of just the inactive ones.
If you want to try and see what happens if the kernel doesn't evict those, you can recompile the kernel with this patch, seen in this question. What should happen is that the OS should freeze for at most 1 second now instead of minutes(or permanently) and there should be little to no disk thrashing.
edited Aug 31 at 13:44
Thomas Ward♦
41.5k23112166
answered Aug 31 at 10:33
Marcus Linsner
113
edited Aug 31 at 13:44
Thomas Ward♦
41.5k23112166
edited Aug 31 at 13:44
Thomas Ward♦
41.5k23112166
edited Aug 31 at 13:44
Thomas Ward♦
41.5k23112166
41.5k23112166
answered Aug 31 at 10:33
Marcus Linsner
113
answered Aug 31 at 10:33
Marcus Linsner
113
answered Aug 31 at 10:33
Marcus Linsner
113
113
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1017884%2fubuntu-freeze-when-low-memory%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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
Nothing's wrong. When a system runs out of memory, it'll fall back to using the swapfile which can grind the OS to a halt. There isn't a way to use a lot of swap and maintain system responsiveness because permanent storage devices are slow by nature.
– dsstorefile1
Mar 21 at 9:30
Can you include the output from:
cat /proc/cmdline? Also4.15.1is old. The newest is4.15.11: kernel.ubuntu.com/~kernel-ppa/mainline/v4.15.11– WinEunuuchs2Unix
Mar 21 at 10:56
1
I'm seeing this issue too, and I'm interested why this didn't happen in Ubuntu < 17.10. Let me reinforce: I've never seen my system freeze due to exhaustion of RAM (for years). - I've noticed that GNOME Shell seems to use significantly more RAM than Unity used to, but that very problem shouldn't be tied to the desktop, should it?
– Peterino
Mar 27 at 9:16
1
Another case here. @dsstorefile: in my case (and I guess other users too) the system doesn't grind to a halt but often rather just stops completely with no warning.
– Erik I
Apr 23 at 2:12
1
Same happens here as well. An unresponsive system due to swapping is one thing, but here the system goes from "everything is fine" to "I can't even move my mouse anymore" within a second. I am pretty sure this is not intended behavior.
– Plankalkül
Jul 21 at 14:59