Bug 853602 - Installer high memory usage
Installer high memory usage
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
:
: 853794 854155 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-01 02:59 EDT by Jan ONDREJ
Modified: 2014-02-05 07:07 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 07:07:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda.log, the guest has 768mb ram and anaconda request 1gb (3.22 KB, text/plain)
2012-09-01 12:08 EDT, Reartes Guillermo
no flags Details
anaconda out of memory error (255.23 KB, text/plain)
2012-09-01 12:10 EDT, Reartes Guillermo
no flags Details
idem, program.log (43.85 KB, text/plain)
2012-09-01 12:11 EDT, Reartes Guillermo
no flags Details

  None (edit)
Description Jan ONDREJ 2012-09-01 02:59:29 EDT
Description of problem:
Fedora 18 installer is swapping on 1 GB RAM system.

Version-Release number of selected component (if applicable):
Todays Fedora 18 development.

How reproducible:
always

Steps to Reproduce:
1. booted using PXE
2. selected minimal install using kickstart
3. switched to F2 and run top
  
Actual results:
950 MB RAM used
300 MB swap used
aprox. 400 MB cache allocated

Expected results:
no swap used

Additional info:
My installation is slow, because this system is swapping.
Unable to clean cache, even if I set vm.swappiness=1 and run:
  sync; echo 3 > /proc/sys/vm/drop_caches
Still 400 MB cache is used.
I think installation on a 1 GB system should run without swapping.
Comment 1 Reartes Guillermo 2012-09-01 12:08:41 EDT
Created attachment 608900 [details]
anaconda.log, the guest has 768mb ram and anaconda request 1gb

It happened after hitting an unknown error, which i tried to auto-report, but a second unknown error happened and the guest became hyper-slow. I do not know if anaconda now requires 1gb or if it was a bug somewhere.
Comment 2 Reartes Guillermo 2012-09-01 12:10:13 EDT
Created attachment 608901 [details]
anaconda out of memory error
Comment 3 Reartes Guillermo 2012-09-01 12:11:59 EDT
Created attachment 608902 [details]
idem, program.log
Comment 4 Chris Lumens 2012-09-03 15:09:51 EDT
*** Bug 853794 has been marked as a duplicate of this bug. ***
Comment 5 Chris Lumens 2012-09-04 11:31:28 EDT
*** Bug 854155 has been marked as a duplicate of this bug. ***
Comment 6 Will Woods 2012-09-04 12:29:30 EDT
Can you attach the boot arguments and/or kickstart used?

Most importantly, what method is being used to get the installer runtime image? http/https/ftp has much higher memory usage than nfs/hd/cdrom, so that could be a contributing factor...

Also, these logs show anaconda running with 768MB RAM, not 1GB. Does it also fail with 1GB? Can you attach a log showing this? Could you also get 'ps aux' output or some other details about what's actually *using* all the RAM?
Comment 7 Jan ONDREJ 2012-09-04 13:12:05 EDT
(In reply to comment #6)
> Can you attach the boot arguments and/or kickstart used?
> Most importantly, what method is being used to get the installer runtime
> image? http/https/ftp has much higher memory usage than nfs/hd/cdrom, so
> that could be a contributing factor...

I use PXE boot, repo=http://... and an kickstart.

My boot options:

repo=http://ftp.upjs.sk/pub/fedora
/linux/development/18/x86_64/os ksdevice=bootif ks=http://boot.salstar.sk/ks/dev
elopment root=live:http://ftp.upjs.sk/pub/fedora/linux/development/18/x86_64/os/
LiveOS/squashfs.img  nomodeset

nomodeset is required in qemu's default cirrus card (not reported yet, that fails to start X without nomodeset).
Similar problems without kickstart too.

> Also, these logs show anaconda running with 768MB RAM, not 1GB. Does it also
> fail with 1GB? Can you attach a log showing this? Could you also get 'ps
> aux' output or some other details about what's actually *using* all the RAM?

My logs are from 1 GB system, which don't fail, but on 1 GB system my system is installing very slowly, due to high swapping. On 1.5 GB system swaps is lower and installation if faster.
Reartes attached different logs, ask him if you need.
Comment 8 Jan ONDREJ 2012-09-04 13:39:31 EDT
(In reply to comment #6)
> Also, these logs show anaconda running with 768MB RAM, not 1GB. Does it also
> fail with 1GB? Can you attach a log showing this? Could you also get 'ps
> aux' output or some other details about what's actually *using* all the RAM?

I can't reproduce this today, possibly due to another bug. Installer starts to format partitions, but after some time my install screen is black and on F1 console there is "Pane id dead" message on last row. :-(

Another bug: After clear of whole disk I can't assign new disk areas. Instead of starting disk selector it says only: Error checking storage configuration.
Switching to F2 and formatting disk using fdisk does not help.

Later I was able to start manual partitioning, but clicking on "Click here to create them automatically" killed my system. An unknown error has occured was displayed, but unable to click on "More info..." or "Report bug", so I can't tell more.
Comment 9 Will Woods 2012-09-04 13:49:47 EDT
Well, I can reproduce this with Fedora-18-Alpha-TC5-x86_64-netinst.iso - meaning not using 'repo=http://...'. The crash happens when you try to commit the partitioning.

It looks like the traceback is caused by 'modprobe scsi_wait_scan' failing, due to lack of memory. (As a side note, there's no scsi_wait_scan module in the image, because it's not in the kernel RPM anymore - I think it's been removed).

Hard to say immediately what's using all the RAM. It's not the http:// repo though, so ignore that.
Comment 10 Jesse Keating 2012-09-04 18:22:58 EDT
Assigning to Will only because he started looking at it.  Want to avoid duplication of work.
Comment 11 Reartes Guillermo 2012-09-04 19:36:48 EDT
> Reartes attached different logs, ask him if you need.

In my case (853794) i did not use any kickstart, just he regular dvd iso.

And in my case the system became slow after an "unknown error" in which "report bug" also failed.
Comment 12 Jason Montleon 2012-09-16 10:31:02 EDT
I created a VM with 1GB of RAM and the installer died in various places. After 6 or 7 tries I upped it to 2GB and the installer was able to proceed normally. In particular entering the disk partitioning section and performing custom partitioning seemed to be at least the beginning of the slow down, if not the end of any meaningful progress.
Comment 13 Fedora End Of Life 2013-12-21 03:49:36 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 14 Fedora End Of Life 2014-02-05 07:07:48 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.