Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
![]() |
World Community Grid Forums
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 4
|
![]() |
Author |
|
jay_Orlando
Senior Cruncher USA Joined: Jan 4, 2006 Post Count: 181 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Please see https://www.worldcommunitygrid.org/forums/wcg...ead,42178_offset,0#623068
----------------------------------------I originally posted in Mapping Cancer Markers (above) . Has anyone else seen this?? ONLY when I run Mapping Cancer Markers.. (So I posted here, instaed of BOINC forum. Should I pst there?) This is strange. It is Boinc Manager - not boinc-client or the WU tasks themselves. It is repeatable on different machines - different versions of Ubuntu. Details are in the link above. No errors or aborts. Thanks!! Jay ![]() |
||
|
adriverhoef
Master Cruncher The Netherlands Joined: Apr 3, 2009 Post Count: 2174 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Jay,
----------------------------------------You said you used htop to watch this particular behaviour. I'm seeing that, too, when using htop. However, when using ps or top I'm not seeing that. $ ps l | sed -n 's/ .....//; 1p; /Kit/p' Using htop, besides seeing 97G being used by 6 instances of WebKitNetworkProcess and 10 instances of WebKitWebProcess each, I'm seeing 10 instances of atril (a PDF viewer) using even more VIRT memory: 98G each. Using ps, I'm seeing nothing out of the ordinary (in column VSZ): $ ps alx | sed -n 's/ .....//; 1p; /atril/p; /boinc/p; /Kit/p' ![]() UPDATE: Closing atril and boincmgr removes all (gigantic) instances of WebKitNetworkProcess and WebKitWebProcess in htop (not running any MCM1 now). Opening atril again creates enormous VIRT instances of atril, WebKitNetworkProcess and WebKitWebProcess in htop. UPDATE 2: (Closing atril for a while now.) Opening and closing boincmgr has the same effect (when not running MCM1) in htop: - opening boincmgr creates huge VIRT instances of boincmgr, WebKitNetworkProcess and WebKitWebProcess; - closing boincmgr removes all instances of WebKitNetworkProcess and WebKitWebProcess (and boincmgr, of course). [Edit 6 times, last edit by adriverhoef at Apr 3, 2020 12:38:27 PM] |
||
|
jay_Orlando
Senior Cruncher USA Joined: Jan 4, 2006 Post Count: 181 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Hello Adri, greetings!!
----------------------------------------First, what caught my attention was the time the WU processes spent in 'sytem' time - about 20% to 30%.(This showed up with gkrellm) The virtual size was so large, it distracted me. I was using top, htop, ps, gkrellm, and the Mate system monitor individually to guess what was going on. The Virtual mem size may be a false trail. But it was so large, I jumped to a conclusion that it was important, Then, I started reading.... (uh-oh.) The 'man' page for top had a good explanation.... Linux Memory Types For our purposes there are three types of memory, and one is optional. First is physical memory, a limited resource where code and data must reside when executed or referenced. Next is the optional swap file, where modified (dirty) memory can be saved and later retrieved if too many demands are made on physical memory. Lastly we have virtual memory, a nearly unlimited resource serving the following goals: 1. abstraction, free from physical memory addresses/limits 2. isolation, every process in a separate address space 3. sharing, a single mapping can serve multiple needs 4. flexibility, assign a virtual address to a file Regardless of which of these forms memory may take, all are managed as pages (typically 4096 bytes) but expressed by default in top as KiB (kibibyte). The memory discussed under topic `2c. MEMORY Usage' deals with physical memory and the swap file for the system as a whole. The memory reviewed in topic `3. FIELDS / Columns Display' embraces all three memory types, but for individual processes. For each such process, every memory page is restricted to a single quadrant from the table below. Both physical memory and virtual memory can include any of the four, while the swap file only includes #1 through #3. The memory in quadrant #4, when modified, acts as its own dedicated swap file.
The following may help in interpreting process level memory values displayed as scalable columns and discussed under topic `3a. DESCRIPTIONS of Fields'. %MEM - simply RES divided by total physical memory CODE - the `pgms' portion of quadrant 3 DATA - the entire quadrant 1 portion of VIRT plus all explicit mmap file-backed pages of quadrant 3 RES - anything occupying physical memory which, beginning with Linux-4.5, is the sum of the following three fields: RSan - quadrant 1 pages, which include any former quadrant 3 pages if modified RSfd - quadrant 3 and quadrant 4 pages RSsh - quadrant 2 pages RSlk - subset of RES which cannot be swapped out (any quadrant) SHR - subset of RES (excludes 1, includes all 2 & 4, some 3) SWAP - potentially any quadrant except 4 USED - simply the sum of RES and SWAP VIRT - everything in-use and/or reserved (all quadrants) Note: Even though program images and shared libraries are considered private to a process, they will be accounted for as shared (SHR) by the kernel. ... later ... 45. VIRT -- Virtual Memory Size (KiB) The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out and pages that have been mapped but not used.
I could see the Virtual memory size with ps as ps -eo pid,drs,rss,vsz,user,fname --headers ---- SO. I have ARP, MIP, HST WU running with an Einstein WU on the GPU - with an assigned CPU. - without any system time showing up in gkrellm. When these complete, I will try MCM again, and tinker about some more. Thank you for verifying the LARGE VMem sizes used!! Jay ![]() |
||
|
jay_Orlando
Senior Cruncher USA Joined: Jan 4, 2006 Post Count: 181 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
---------------------------------------- ![]() |
||
|
|
![]() |