Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RAM informations are wrong on Darwin OS #112

Open
JoffreyPoreeCoding opened this issue Oct 16, 2020 · 4 comments
Open

RAM informations are wrong on Darwin OS #112

JoffreyPoreeCoding opened this issue Oct 16, 2020 · 4 comments

Comments

@JoffreyPoreeCoding
Copy link

Hello,

I'm using Mac OS 10.15.6 (Catalina) and getRam function return incorrect result.

Here explained :

use Linfo\Linfo;

require 'vendor/autoload.php';

$linfo = (new Linfo())->getParser();

print_r($linfo->getRam());

Result :

Array
(
    [type] => Physical
    [total] => 17179869184
    [free] => 17432133632
    [swapTotal] => 0
    [swapFree] => 0
    [swapInfo] => Array
        (
        )

)

As you can see, free mem is greater than available. sysctl hw.usermem return `hw.usermem: -216473600'. So I try to take only the absolute value (216473600) but it still wrong.

My current free RAM is about 3Gb.

A little trick allow me to get the free RAM in Dawin.php (I don't like to "unitPows trick but... it works)

$freeMemory = trim($this->exec->exec('top', '-l 1 | grep PhysMem | sed "s/.*, //" | sed "s/ .*//"'));
$unitPows = [
    'K' => 1,
    'M' => 2,
    'G' => 3,
];

$unit = substr($freeMemory, -1);
$freeMemory = (int) $freeMemory;
$freeMemory = $freeMemory * pow(1024, $unitPows[$unit]);

Gives me 2008023040 (2Gb because my RAM available is about 2Gb ^^)

Hope you will find a fix with sysctlvelse I can make a merge request to put modification.

@jrgp
Copy link
Owner

jrgp commented Oct 17, 2020

Hey,

Thanks for the report.

This problem is likely due to the mac sysctl entries being bounded by the size of a 32bit integer, which is why the value for hw.usermem overflowed and became negative. This wasn't caught when the Linfo Darwin OS class was written 10 years ago as computers had less ram back then.

The proper fix here is to have Linfo execute vm_stat and regex-match out the right values, as opposed to the current implementation which tries extract the info from sysctl.

While the top shell pipeline approach would work, it's more efficient to execute just one command (vm_stat) as opposed to executing 4.

@JoffreyPoreeCoding
Copy link
Author

Yeah sure it's better to use vm_stat, will you fix it soon ?

@jrgp
Copy link
Owner

jrgp commented Nov 22, 2020

Per 6ce9284 I've committed a patch that "fixes" the value being reported as negative.

It still isn't accurate though as it doesn't take into account memory which is used for filesystem cache nor compressed memory regions

@JoffreyPoreeCoding
Copy link
Author

Ok nice, thanks you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants