淘寶商品庫是淘寶網最核心的數(shù)據(jù)庫之一，采用MySQL主備集群的架構，特點是數(shù)據(jù)量大且增長速度快，讀多寫少，對安全性要求高，并發(fā)請求高。
演講內容包括淘寶商品庫硬件的選型決策， 安全性和性能的平衡，特別是創(chuàng)新引入PCI-E
Flash卡和Flashcache作為Cache提高IO性能，在保證安全性的前提下就包括MySQL、InnoDB引擎、文件系統(tǒng)、系統(tǒng)Page
Cache、
IO調度算法、DM層（Flashcache）、Raid卡、設備驅動在內的整條IO路徑的Cache進行優(yōu)化，進一步挖掘了系統(tǒng)IO的潛能，重點介紹優(yōu)
化過程中的一些經驗教訓、測量手段和工具。
玩得開心！
最近關于Erlang程序在異常打印堆棧時候帶上行號信息的提案開始被討論了，具體看這里：
EEP 36: Line numbers in exceptions: http://www./eeps/eep-0036.html
初學Erlang的人估計都有這個困惑，程序異常的時候打印堆棧不假，但是只打出函數(shù)名，如果模塊很長的話，很難找到具體發(fā)生異常的點，通常再通過
打日志的方式來定位，非常的低效無聊。有人開玩笑說是Erlang鼓勵寫短函數(shù)和模塊. 我曾經想了個方法解決這個問題, 見 這里 ， 但不是完美的方案。
EEP 36則是從編譯器直接搞定這個問題，會爽很多, 我們看下他的效果：
Read more…
最近有同學反映在某些新機器上做性能調優(yōu)的時候， oprofile 有時抓不到數(shù)據(jù)，我之前也遇到這個情況，很是無語，今天特地驗證了下。
# 我們的操作系統(tǒng)和機器配置大概是這樣的： |
# Aspersa System Summary Report ############################## |
Date | 2011-03-31 16:26:05 UTC (local TZ: CST +0800) |
Hostname | my031226.sqa.cm4 |
Uptime | 10:00, 4 users, load average: 0.00, 0.78, 5.29 |
System | Huawei Technologies Co., Ltd.; Tecal RH2285; vV100R001 (Main Server Chassis) |
Service Tag | 2102317716N0AA000062 |
Release | Red Hat Enterprise Linux Server release 5.4 (Tikanga) |
Architecture | CPU = 64-bit, OS = 64-bit |
Compiler | GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-44). |
# Processor ################################################## |
Processors | physical = 2, cores = 12, virtual = 24, hyperthreading = yes |
Models | 24xIntel(R) Xeon(R) CPU X5670 @ 2.93GHz |
$sudo rm -f /root/.oprofile/daemonrc |
$sudo opcontrol --setup --no-vmlinux |
Using 2.6+ OProfile kernel interface. |
Using log file /var/lib/oprofile/samples/oprofiled.log |
$sudo opcontrol --shutdown |
opreport error: No sample file found: try running opcontrol --dump |
or specify a session containing sample files |
$tree /var/lib/oprofile/samples/current/ |
/var/lib/oprofile/samples/current/ |
確實是沒抓到sample文件！
經過無數(shù)次的分析和判斷，再加上goolge大神的幫助，找到問題的根源了:
Read more…
晚上 雕梁 說要找個工具來調查下unix域套接字的發(fā)送和接受情況，比如說A程序是否送出，B程序是否接收到，他找了tcpdump ,wireshark什么的，貌似都不支持。
這時候還是偉大的systemtap來救助了。 因為所有的socket通訊都是通過socket接口來的，任何family的通訊包括unix域套接都要走的，所以只要截獲了socket 讀寫的幾個syscall 就搞定了.
systemtap發(fā)行版本提供了個工具socktop， 位于 /usr/share/doc/systemtap/examples/network/socktop, 是個非常方便的工具, 干這個事情最合適了。
Read more…
看圖不說話：
我們在系統(tǒng)調優(yōu)或者定位問題的時候，經常會發(fā)現(xiàn)多線程程序的效率很低，但是又不知道問題出在哪里，就知道上下文切換很多，但是為什么上下文切換，是誰導致切換，我們就不知道了。上下文切換可以用dstat這樣的工具查看，比如：
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- |
usr sys idl wai hiq siq| read writ| recv send| in out | int csw |
9 2 87 2 0 1|7398k 31M| 0 0 | 9.8k 11k| 16k 64k |
20 4 69 3 0 4| 26M 56M| 34M 172M| 0 0 | 61k 200k |
21 5 64 6 0 3| 26M 225M| 35M 175M| 0 0 | 75k 216k |
21 5 66 4 0 4| 25M 119M| 34M 173M| 0 0 | 66k 207k |
19 4 68 5 0 3| 23M 56M| 33M 166M| 0 0 | 60k 197k |
$sudo stap -e 'global cnt; probe scheduler.cpu_on {cnt<<<1;} probe timer.s(1){printf("%d\n", @count(cnt)); delete cnt;}' |
每秒高達200k左右的的上下文切換， 誰能告訴我發(fā)生了什么? 好吧，latencytop來救助了!
它的官網：http://www./
Skipping audio, slower servers, everyone knows the symptoms of latency.
But to know what’s going on in the system, what’s causing the latency,
how to fix it… that’s a hard question without good answers right now.
LatencyTOP is a Linux* tool for software developers (both kernel and
userspace), aimed at identifying where in the system latency is
happening, and what kind of operation/action is causing the latency to
happen so that the code can be changed to avoid the worst latency
hiccups.
它是Intel貢獻的另外一個性能查看器，還有一個是powertop,都是很不錯的工具.
Read more…
|
