淘寶商品庫(kù)是淘寶網(wǎng)最核心的數(shù)據(jù)庫(kù)之一，采用MySQL主備集群的架構(gòu)，特點(diǎn)是數(shù)據(jù)量大且增長(zhǎng)速度快，讀多寫少，對(duì)安全性要求高，并發(fā)請(qǐng)求高。
演講內(nèi)容包括淘寶商品庫(kù)硬件的選型決策， 安全性和性能的平衡，特別是創(chuàng)新引入PCI-E
Flash卡和Flashcache作為Cache提高IO性能，在保證安全性的前提下就包括MySQL、InnoDB引擎、文件系統(tǒng)、系統(tǒng)Page
Cache、
IO調(diào)度算法、DM層（Flashcache）、Raid卡、設(shè)備驅(qū)動(dòng)在內(nèi)的整條IO路徑的Cache進(jìn)行優(yōu)化，進(jìn)一步挖掘了系統(tǒng)IO的潛能，重點(diǎn)介紹優(yōu)
化過(guò)程中的一些經(jīng)驗(yàn)教訓(xùn)、測(cè)量手段和工具。
玩得開心！
最近關(guān)于Erlang程序在異常打印堆棧時(shí)候帶上行號(hào)信息的提案開始被討論了，具體看這里：
EEP 36: Line numbers in exceptions: http://www./eeps/eep-0036.html
初學(xué)Erlang的人估計(jì)都有這個(gè)困惑，程序異常的時(shí)候打印堆棧不假，但是只打出函數(shù)名，如果模塊很長(zhǎng)的話，很難找到具體發(fā)生異常的點(diǎn)，通常再通過(guò)
打日志的方式來(lái)定位，非常的低效無(wú)聊。有人開玩笑說(shuō)是Erlang鼓勵(lì)寫短函數(shù)和模塊. 我曾經(jīng)想了個(gè)方法解決這個(gè)問(wèn)題, 見 這里 ， 但不是完美的方案。
EEP 36則是從編譯器直接搞定這個(gè)問(wèn)題，會(huì)爽很多, 我們看下他的效果：
Read more…
最近有同學(xué)反映在某些新機(jī)器上做性能調(diào)優(yōu)的時(shí)候， oprofile 有時(shí)抓不到數(shù)據(jù)，我之前也遇到這個(gè)情況，很是無(wú)語(yǔ)，今天特地驗(yàn)證了下。
# 我們的操作系統(tǒng)和機(jī)器配置大概是這樣的： |
# 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/ |
確實(shí)是沒(méi)抓到sample文件！
經(jīng)過(guò)無(wú)數(shù)次的分析和判斷，再加上goolge大神的幫助，找到問(wèn)題的根源了:
Read more…
晚上 雕梁 說(shuō)要找個(gè)工具來(lái)調(diào)查下unix域套接字的發(fā)送和接受情況，比如說(shuō)A程序是否送出，B程序是否接收到，他找了tcpdump ,wireshark什么的，貌似都不支持。
這時(shí)候還是偉大的systemtap來(lái)救助了。 因?yàn)樗械膕ocket通訊都是通過(guò)socket接口來(lái)的，任何family的通訊包括unix域套接都要走的，所以只要截獲了socket 讀寫的幾個(gè)syscall 就搞定了.
systemtap發(fā)行版本提供了個(gè)工具socktop， 位于 /usr/share/doc/systemtap/examples/network/socktop, 是個(gè)非常方便的工具, 干這個(gè)事情最合適了。
Read more…
看圖不說(shuō)話：
我們?cè)谙到y(tǒng)調(diào)優(yōu)或者定位問(wèn)題的時(shí)候，經(jīng)常會(huì)發(fā)現(xiàn)多線程程序的效率很低，但是又不知道問(wèn)題出在哪里，就知道上下文切換很多，但是為什么上下文切換，是誰(shuí)導(dǎo)致切換，我們就不知道了。上下文切換可以用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;}' |
每秒高達(dá)200k左右的的上下文切換， 誰(shuí)能告訴我發(fā)生了什么? 好吧，latencytop來(lái)救助了!
它的官網(wǎng)：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貢獻(xiàn)的另外一個(gè)性能查看器，還有一個(gè)是powertop,都是很不錯(cuò)的工具.
Read more…
|
