淺入淺出 MySQL & PostgreSQL // Speaker Deck
(speakerdeck.com)
40 則討論
IngramChen
張貼於
這是文章的子討論串，你可以回到上層查看所有討論和文章
IngramChen
積分 1
其實 postgres 的 buffer 預設的更小，預設值根本是給 1G ram 不到的電腦用的...
因為 PostgreSQL 與 MySQL 理念哲學不同。
PostgreSQL 認為 OS file caching 已經做得很好了，所以很多 cache 都是在 OS level；反之 MySQL 認為什麼都自己管效率才高，因此什麼東西都放在自己的 cache。
以致於，
PostgreSQL 較 MySQL 更依賴作業系統及其檔案系統，稍有不同效能就會有差 (例如 Linux kernel 或 FS 的選用就會有不一樣的差異)；而 MySQL 比較沒有這個問題。這也導致 PostgreSQL 社群會特別關注 Linux kernel 每個版本所帶來的影響，但 Linux kernel 也不可能為了 PostgreSQL 就調整什麼，畢竟 Linux kernel 不是只給 PostgreSQL 執行。
PostgreSQL shared buffer 不能設定太高，因為要保留給 OS file caching；反之，MySQL 因為都自己管，所以要設定得很高。放在同一個 pool 有一個好處，就是資源共享，反之 PostgreSQL 的 shared buffer 不管太高或太低都沒有辦法跨出這個設定值去用預留太多或太少的 OS file caching。另外，這也造成 MySQL 在單機多實例的運用下較有優勢 (如果有需要的話)。
以上，是我在簡報沒講的 Part 2 內容之一。
IngramChen
積分 5
謝謝解說，我自己的經驗也是如此。前些日子將 Java App 的 heap 調低 1GB，將它歸還給 OS 運用。果不期然 PostgreSQL 的 Disk IO 就變小了 (db 和 web app 放同台機器)
HYL
積分 0
岔題，很久很久前，我們單位的習慣是，既使是有 8GB Ram 的機器，仍是留了一半的空間給 OS 來調用，只有 4GB 是給 JVM 用。
不知道大家的習慣是？
qrtt1
積分 2
我比較習慣看峰值的剩餘空間，希望 OS 至少還有 1GB 能用比較安心，不然記憶體用多的程式可能會遇上 kernel 的 oom killer 就麻煩了。
IngramChen
積分 3
我們以前部署的機器，15GB ram ，我的 JVM heap 就開 14GB，留 1GB 給 OS，結果十幾台主機一週就當個二、三個 jvm。一開始以為踩到 JVM bug，造成 segment fault (畢竟沒有開過 1xGB heap 過，怕怕)，查到最後才發現是 OOM killer 會殺。這就很納悶了，不是已經留 1GB 給 OS 了？後來調降到 12 GB 後就再也沒發生過了。
原因沒有詳查，但多半是服務太大，所以 OS 會需要更多的資源 (socket...etc)
所以你講到重點了，是 峰值的剩餘空間 後，還保留個 1GB 左右是安全值，尤其是配置大量的 JVM heap。以前傻傻的直接用硬體 ram 去估算做不得準啊。
IngramChen
積分 0
看主機上有沒有其他服務，如果沒有的話大部份都會配給 JVM，除非已經知道該服務是 I/O heavy，需要大量 OS disk cache。
不過我沒有配置過 16GB 以上的 JVM heap 了，聽說到了這個階段 garbage collection 就很難調了 (指 hotspot jvm)，很多服務到這階段就會開始拆 server，而不是硬撐 vertical scale up 上去。
其實不要開太大還有個好處是 memory leak 時，能夠及早發現及早治療。萬一是爆在 1x GB 把 memory dump 出來要用 mat1 來看誰是兇手也很麻煩。