[C] 查看目前程式的記憶體用量 @ macOS 10.15

記得碩士生活很常被記憶體追殺，那時都是靠 unix tools 或是 /proc/ 查看指定的記憶體，都忘了其實是靠 process 自己去查詢資料，這次工作要協助 debug 抓資訊，就把它完成了：

#include <stdio.h>
#include <stdlib.h>

// Memory Usage
#include <sys/types.h>
#include <sys/sysctl.h>

void simple_wait() {
size_t wait_buf_size = 32;
char *wait_buf;
wait_buf = (char *)malloc(wait_buf_size * sizeof(char));
getline(&wait_buf, &wait_buf_size, stdin);
free(wait_buf);
}

void show_memory_usage() {
struct rusage usage;
printf("\n-- Memory Usage -- Begin --\n");

if(0 == getrusage(RUSAGE_SELF, &usage)) {
printf("\tBytes:\t%ld\n", usage.ru_maxrss);
printf("\t= \t%.3f KB\n", usage.ru_maxrss / 1024.0);
printf("\t= \t%.3f MB\n", usage.ru_maxrss / 1024.0 / 1024.0);
} else {
printf("\tREAD ERROR\n");
}

printf("-- End -- Memory Usage --\n");
}

int main(int argc, char *argv[]) {

show_memory_usage();
printf("press enter to continue\n");
simple_wait();

return 0;
}

用法：

$ gcc t.c
$ ./a.out

-- Memory Usage -- Begin --
Bytes: 671744
= 656.000 KB
= 0.641 MB
-- End -- Memory Usage --
press enter to continue

只是在 man page: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/getrusage.2.html 的描述：

ru_maxrss    the maximum resident set size utilized (in kilobytes).

但看數據總覺得是 bytes 啊 XD 先記錄起來，有空再追蹤

[Linux] 使用常見的指令進行系統監控 @ Ubuntu 14.04

取得 Server 代號 - 使用 hostname 指令：

$ hostname

取得 Server OS 資訊 - 使用 lsb_release 指令：

$ lsb_release -a

取得 CPU 使用率 - 使用 vmstat、tail 和 awk 指令：

$ echo $((100-$(vmstat|tail -1|awk '{print $15}')))

取得 System Loading 資訊 - 使用 uptime 和 awk 指令：

$ uptime | egrep -o 'load average[s]*: [0-9,\. ]+' | awk -F',' '{print $1$2$3}' | awk -F' ' '{print $3}'
$ uptime | egrep -o 'load average[s]*: [0-9,\. ]+' | awk -F',' '{print $1$2$3}' | awk -F' ' '{print $4}'
$ uptime | egrep -o 'load average[s]*: [0-9,\. ]+' | awk -F',' '{print $1$2$3}' | awk -F' ' '{print $5}'

取得 Apache Web Server Processes 資訊 - 使用 pgrep 跟 wc 指令：

$ pgrep apache2 | wc -l

取得 Memory 使用率 - 使用 free、grep 跟 awk 指令：

$ free -m | grep Mem | awk '{print $3/$2 * 100}'

取得 Network 即時流量 - 使用 nicstat、grep 跟 awk，假定網路卡是 eth 開頭：

In:
$ nicstat | grep eth |  awk '{print $3}'

Out:
$ nicstat | grep eth |  awk '{print $4}'

最後，檢查上述指令是否都存在：

#!/bin/sh
CMD_USAGE=$(echo 'hostname curl pgrep wc awk tail uptime vmstat free nicstat' | tr ";" "\n")
for cmd in $CMD_USAGE
do
        path=`which $cmd`
        if [ -z $path ] || [ ! -x $path ] ; then
                echo "$cmd not found"
                exit
        fi
done

其他資源：

• slideshare - Linux Performance Tools
• slideshare - Linux Performance Analysis and Tools
• slideshare - What Linux can learn from Solaris performance and vice-versa

iOS 開發筆記 - ALAssetsLibrary assetForURL defaultRepresentation fullResolutionImage - Terminated due to Memory Pressure

最近設計 app 時，開始把圖片存進內建得相本裡，而不使用 app sandbox 空間，然而要取出圖片時，就會碰到 Terminated due to Memory Pressure 的問題，追一下，大概是瞬間取太多張照片 :P 此為 ARC 模式。

解法：

1. 降低瞬間取照片的數量
2. 使用 @autoreleasepool{ } 處理記憶體管理

例如：

[self.library assetForURL:[NSURL URLWithString:@"assets-library://..."] resultBlock:^(ALAsset *asset) {
                                //NSLog(@"asset:%@",asset);
                                UIImage *image = nil;
                                @autoreleasepool {
                                    image = [UIImage imageWithCGImage:[[asset defaultRepresentation] fullResolutionImage]];
                                }
                            } failureBlock:^(NSError *error) {
                            }];

只是，這樣也沒有真的避免大量記憶體的使用 Orz 因為 [asset defaultRepresentation] fullResolutionImage] 真的吃滿大的記憶體，例如 5MB 大小的照片，處理一張照片時，記憶體會瞬間加了 30~50MB，所以瞬間處理 3~5 張時，記憶體還可能衝到 2xxMB ，直到 Terminated due to Memory Pressure。暫時想到的解法就只能透過降低處理照片的張數了。

實際例子是 app 初始化完大概 20MB 記憶體，跑上述 code 處理 3 張照片可以吃到 90MB，不曉得是不是 CGImage 的關係？改天有空再追一下。

[PHP] 使用 Memory Cache (php://memory) 加速 File Handle 操作

最近使用 maxmind / MaxMind-DB-Reader-php 時，發現大量處理很慢，研究一下 src / MaxMind / Db / Reader.php 後，發現 DB 沒有一口氣讀進記憶體使用，就找一下如何將檔案搬進 Memory 後，一樣用 File Handle 對 memory 操作，如此可以降低 source code 的更動。

用法(以 src / MaxMind / Db / Reader.php 為例)：

$this->fileHandle = @fopen($database, 'rb');
if ($this->fileHandle === false) {
throw new \InvalidArgumentException(
"Error opening \"$database\"."
);
}

$this->fileSize = @filesize($database);
if ($this->fileSize === false) {
throw new \UnexpectedValueException(
"Error determining the size of \"$database\"."
);
}

// Add by changyy
$fp = fopen("php://memory", 'rb+');
if(is_resource($fp)) {
fputs($fp, fread($this->fileHandle, $this->fileSize) );
rewind($fp);
fclose($this->fileHandle);
$this->fileHandle = $fp;
}

使用的結果，在 Linode 2048 的機器上，測試 20k 筆資料，未加時約 65 秒，加了可以進步到 40 秒附近，稍微失落 Orz 此外，可以用 memory_get_peak_usage() 來的知記憶體的增減。

[Linux] 監控記憶體使用量，以 python 為例 @ Ubuntu 12.04

監控方式就...去翻 /proc/pid/status 來看

粗略測試方式：

• 寫一隻程式，最後一行跑 loop 讓程式不會結束，或是讀 io卡住也行
• 用 ps 得知此程式 pid，接著翻 /proc/pid/status 出來

例如我想知道 python 記憶體使用上會不會 copy by reference 或 copy by reference，那就重複把某個 string data 設值給別人看看，最後用一個 loop 卡住，讓程式不會結束，接著就用 ps aux | grep 'test.py' 去找出來 PID ，再去 cat /proc/PID/status 出來。

test.py：

import time

data = open('tmp').read()
i = 1000
co = []
while i > 0 :
        #co.append(str(data)+"1")
        #co.append(str(data)+"")
        co.append(str(data))
        i -= 1
print "Done:", len(co)
while True:
        time.sleep(1)

連續動作：

$ ps aux | grep test.py | grep -v "grep\|vim" | awk '{system("cat /proc/"$2"/status");}' | grep -i "pid\|vm\|name"

當 co.append(str(data)) 跟 co.append(str(data)+"") 時，i 數值變大對記憶體增加不多：

Name:   python
Pid:    12180
PPid:   11910
TracerPid:      0
VmPeak:    32532 kB
VmSize:    32532 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:      5676 kB
VmRSS:      5676 kB
VmData:     2700 kB
VmStk:       136 kB
VmExe:      2496 kB
VmLib:      5240 kB
VmPTE:        72 kB
VmSwap:        0 kB

但 co.append(str(data)+" ") 時，i 數值變大對記憶體就開始噴了：

Name:   python
Pid:    12189
PPid:   11910
TracerPid:      0
VmPeak:   340532 kB
VmSize:   340532 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:    313496 kB
VmRSS:    313496 kB
VmData:   310700 kB
VmStk:       136 kB
VmExe:      2496 kB
VmLib:      5240 kB
VmPTE:       680 kB
VmSwap:        0 kB