Bigegg Lab

2011年 7月 9日

このサーバは接続を受け入れきれずに、SYNを取りこぼしてしまっているみたいです。memcachedのbacklogはデフォルト値を使用しているので1024になっているはずです。

$ memcached -h | grep backlog
-b            Set the backlog queue limit (default 1024)

これって、本当に1024で足りなくなっているのでしょうか。単純にバックログを増やせば解決する問題かなと期待しつつも、どうも釈然としなかったので 、man listen をじっくりと読み返していたところ、

backlog 引き数が /proc/sys/net/core/somaxconn の値よりも大きければ、backlog の値は暗黙のうちにこの値に切り詰められる。このファイルのデフォルト 値 は128 である。バージョン 2.4.5 以前のカーネルでは、この上限値はコード埋め込みの固定値 SOMAXCONN であり、その値は 128 であった。

いやーな予感がしたので、おもむろにコマンドを叩いてみると・・・・・

# sysctl net.core.somaxconn
net.core.somaxconn = 128

あちゃあ！
実際はこれ、128になっていたわけですね！

# sysctl -w net.core.somaxconn=1024

としてmemcachedを再起動したところ、大幅に性能が改善されました。

DSAS開発者の部屋:高負荷サイトのボトルネックを見つけるには

TCP接続のリトライが起きているなら変更しておきたい所ですね。
上記設定だとマシンを再起動したら消えてしまう気がします。以下の様に実行すればOKです。
echo “net.core.somaxconn = 1024” » /etc/sysctl.conf
sysctl -p

10ヶ月前 | 固定リンク | 2011年 7月 9日 |

2011年 1月 17日

Avi Kivity suggested that combining KVM, the Kernel-based Virtual Machine [story], with the dyntick patch [story] could improve overall KVM performance. He noted that it would likely improve performance of both the host by “avoiding expensive vmexits due to useless timer interrupts,” as well as on the guest by “reducing the load on the host when the guest is idling (currently an idle guest consumes a few percent cpu)”. Ingo Molnar [interview] pointed out that KVM with his -rt kernel already works with dynticks enabled on both the host and the guest, “using the dynticks code from the -rt kernel makes the overhead of an idle guest go down by a factor of 10-15”. Ingo added that he hopes the dyntick patch will be ready to be merged into the upcoming mainline 2.6.21 kernel.

Rik van Riel [interview] noted that there were other ways to reduce the load of the guest when it’s idling, “you do not need dynticks for this actually. Simple no-tick-on-idle like Xen has works well enough.” Ingo explained, “s390 (and more recently Xen too) uses a next_timer_interrupt() based method to stop the guest tick - which works in terms of reducing guest load, but it doesnt stop the host-side interrupt. The highest quality approach is to have dynticks on both the host and the guest, and this also gives high-resolution timers and a modernized time/timer-events subsystem for both the host and the guest.”

---

From: Avi Kivity [email blocked]
To: Ingo Molnar [email blocked]
Subject: kvm & dyntick
Date:	Thu, 11 Jan 2007 18:08:38 +0200

It occurs to me that kvm could benefit greatly from dyntick:

dyntick-enabled host:
 - generate virtual interrupts at whatever HZ the guest programs its 
timers, be it 100, 250, 1000 or whatever
 - avoid expensive vmexits due to useless timer interrupts

dyntick-enabled guest:
 - reduce the load on the host when the guest is idling
   (currently an idle guest consumes a few percent cpu)

What are the current plans wrt dyntick?  Is it planned for 2.6.21?

-- 
error compiling committee.c: too many arguments to function


From: Rik van Riel [email blocked]
Subject: Re: kvm & dyntick
Date:	Fri, 12 Jan 2007 00:34:34 -0500

Avi Kivity wrote:

> dyntick-enabled guest:
> - reduce the load on the host when the guest is idling
>   (currently an idle guest consumes a few percent cpu)

You do not need dynticks for this actually.  Simple no-tick-on-idle
like Xen has works well enough.

While you're modifying the timer code, you might also want to add
proper accounting for steal time.  Time during which your guest
had a runnable process, but was not actually running itself, should
not be accounted against the currently running process.

I wonder if it would be possible to simply copy some of the timer
code from Xen.  They have the timing quirks worked out very well
and their timer_interrupt() is pretty nice code.

(Now I need to buy myself another VT box so I can help out with KVM :))

http://virt.kernelnewbies.org/ParavirtBenefits has some other features
you may want to have :)))

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.


From: Ingo Molnar [email blocked]
Subject: Re: kvm & dyntick
Date:	Fri, 12 Jan 2007 07:20:07 +0100


* Avi Kivity [email blocked] wrote:

> It occurs to me that kvm could benefit greatly from dyntick:
> 
> dyntick-enabled host:
> - generate virtual interrupts at whatever HZ the guest programs its 
> timers, be it 100, 250, 1000 or whatever
> - avoid expensive vmexits due to useless timer interrupts
> 
> dyntick-enabled guest:
> - reduce the load on the host when the guest is idling
>   (currently an idle guest consumes a few percent cpu)

yeah. KVM under -rt already works with dynticks enabled on both the host 
and the guest. (but it's more optimal to use a dedicated hypercall to 
set the next guest-interrupt)

> What are the current plans wrt dyntick?  Is it planned for 2.6.21?

yeah, we hope to have it in v2.6.21.

note that s390 (and more recently Xen too) uses a next_timer_interrupt() 
based method to stop the guest tick - which works in terms of reducing 
guest load, but it doesnt stop the host-side interrupt. The highest 
quality approach is to have dynticks on both the host and the guest, and 
this also gives high-resolution timers and a modernized 
time/timer-events subsystem for both the host and the guest.

	Ingo


From: Ingo Molnar [email blocked]
Subject: Re: kvm & dyntick
Date:	Fri, 12 Jan 2007 11:19:31 +0100


* Ingo Molnar [email blocked] wrote:

> > dyntick-enabled guest:
> > - reduce the load on the host when the guest is idling
> >   (currently an idle guest consumes a few percent cpu)
> 
> yeah. KVM under -rt already works with dynticks enabled on both the 
> host and the guest. (but it's more optimal to use a dedicated 
> hypercall to set the next guest-interrupt)

using the dynticks code from the -rt kernel makes the overhead of an 
idle guest go down by a factor of 10-15:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2556 mingo     15   0  598m 159m 157m R  1.5  8.0   0:26.20 qemu

( for this to work on my system i have added a 'hyper' clocksource 
  hypercall API for KVM guests to use - this is needed instead of the 
  running-to-slowly TSC. )

	Ingo


From: Avi Kivity [email blocked]
Subject: Re: kvm & dyntick
Date:	Fri, 12 Jan 2007 19:04:31 +0200

Ingo Molnar wrote:
> * Ingo Molnar [email blocked] wrote:
>
>   
>>> dyntick-enabled guest:
>>> - reduce the load on the host when the guest is idling
>>>   (currently an idle guest consumes a few percent cpu)
>>>       
>> yeah. KVM under -rt already works with dynticks enabled on both the 
>> host and the guest. (but it's more optimal to use a dedicated 
>> hypercall to set the next guest-interrupt)
>>     
>
> using the dynticks code from the -rt kernel makes the overhead of an 
> idle guest go down by a factor of 10-15:
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  2556 mingo     15   0  598m 159m 157m R  1.5  8.0   0:26.20 qemu
>
>   

As usual, great news.

> ( for this to work on my system i have added a 'hyper' clocksource 
>   hypercall API for KVM guests to use - this is needed instead of the 
>   running-to-slowly TSC. )
>   

What's the problem with the TSC?  The only issue I'm aware of is that 
the tsc might go backwards if the vcpu is migrated to another host cpu 
(easily fixed).

A pv clocksource makes sense in any case.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Linux: Improving KVM Performance With A Tickless Kernel | KernelTrap

タイマー割り込みを発生させないTickless Kernelのサポートがkernel-2.6.16から導入されました。
これにより、以下のメリットがあります。
・アイドル時の消費電力の低下
・割り込み処理の効率化による、仮想ゲストの性能向上
CentOS-5のkernelは古いので対応していませんが、CentOS-6(RedHat EL6)から、これがサポートされたkernelが使われます。

タイマー割り込みの詳細に関しては、以下の記事が参考になります。

http://eetimes.jp/column/3032

1年前 | 固定リンク | 2011年 1月 17日 |

2010年 11月 24日

kernel	Date	RedHat	CentOS	Fedora	debian	ubuntu
2.6.18	2006/9/20	EL5	5.x	6	4.0 (etch)
2.6.20	2007/2/5					7.04
2.6.21	2007/4/26			7
2.6.22	2007/7/9					7.10
2.6.23	2007/10/10			8
2.6.24	2008/1/25					8.04
2.6.25	2008/4/17			9
2.6.26	2008/7/14				5.0 (lenny)
2.6.27	2008/10/10			10		8.10
2.6.28	2008/12/25					9.04
2.6.29	2009/3/24			11
2.6.30	2009/6/10			12
2.6.31	2009/9/9					9.10
2.6.32	2009/12/4	EL6			6.0? (squeeze)	10.4
2.6.33	2010/2/24
2.6.34	2010/5/16			13
2.6.35	2010/8/1			14
2.6.36	2010/10/x

Fedora 14 Alphaが登場、Linuxカーネルは2.6.35を採用という事なので、4月に書いた各ディストリビューション毎のkernel版数一覧表をUpdateしてみた。

YANO’s digital garage - kernel版数とか

2.6.35以降となるとFedora14しかなさそうですね

1年前 | 固定リンク | 2010年 11月 24日 |

2010年 11月 24日

Depending on your needs, you may be able to use the binary RPMS for your architecture. You have not said what you need from a later kernel. It may be as simple as

wget http://www.centos.toracat.org/ajb/kernel/mainline/x86_64/RPMS/kernel-2.6.35-0.bcat.x86_64.rpm
yum localinstall kernel-2.6.35-0.bcat.x86_64.rpm

Or, for i386:

wget http://www.centos.toracat.org/ajb/kernel/mainline/i386/RPMS/kernel-2.6.35-0.bcat.i686.rpm
yum localinstall kernel-2.6.35-0.bcat.i686.rpm

Is there some reason you need to build from source?

EDIT: A quote from Alan, the creator of the above packages:

Quote:

Before booting this new kernel, users are urged to download and apply the bcat_rc_sysinit.patch, otherwise the system RTC will not be accessible.

_________________
Phil

www.centos.org - Forums - CentOS 5 - Miscellaneous Questions - kernel install from source code

以下の新機能をCentOSで使う方法です。

　Linuxカーネル2.6.35での新機能としては、まずマルチCPU環境でネットワークスループットを向上させる「Receive Packet Steering（RPS）」および「Receive Flow Steering（RFS）」という仕組みの導入が挙げられる。これはGoogleによって提供されたもので、送受信するパケットの処理を複数のCPUに割り当てることで負荷を分散させ、スループットの向上を図るというもの。8コアのCPUを搭載するサーバーで行ったベンチマークテストでは、2〜3倍ものスループット向上やレイテンシの軽減が確認できたという。

　また、カーネルのデバッグに利用できるフロントエンドツール「KDB」も追加された。KDBはSGIによって開発されていたもので、Linux カーネル2.6.26から提供されていたKgdbと異なり、ローカルマシン上で実行できるという特徴がある。いっぽうでソースレベルでのデバッグには対応していないため、状況に応じて利用するデバッガを選択するのが好ましいようだ。

　「Memory compaction」と呼ばれる、メモリの断片化を軽減する仕組みも追加された。これは使用中のメモリページを連続した大きなページに移動することでメモリ使用効率の改善を図るというもの。ページ確保に失敗した際に実行されるほか、「/proc/sys/compact_memory」や「/sys /devices/system/node/nodeN/compact」に任意の値を書き込むことで任意のタイミングで実行させることもできる。

1年前 | 固定リンク | 2010年 11月 24日 |

2010年 10月 15日

Linuxカーネル2.6.35リリース、ネットワーク負荷軽減機構やH.264ハードウェアデコードなどをサポート

2010年08月02日 13:52

　8月1日、Linuxカーネル2.6.35がリリースされた。RPS/RFSと呼ばれるネットワーク負荷軽減機構や新たなカーネルデバッグツールの追加、H.264およびVC-1のハードウェアデコードサポートといった新機能を含む、多くの改善が行われている。

　Linuxカーネル2.6.35での新機能としては、まずマルチCPU環境でネットワークスループットを向上させる「Receive Packet Steering（RPS）」および「Receive Flow Steering（RFS）」という仕組みの導入が挙げられる。これはGoogleによって提供されたもので、送受信するパケットの処理を複数のCPUに 割り当てることで負荷を分散させ、スループットの向上を図るというもの。8コアのCPUを搭載するサーバーで行ったベンチマークテストでは、2〜3倍もの スループット向上やレイテンシの軽減が確認できたという。

　また、カーネルのデバッグに利用できるフロントエンドツール「KDB」も追加された。KDBはSGIによって開発されていたもので、Linux カーネル2.6.26から提供されていたKgdbと異なり、ローカルマシン上で実行できるという特徴がある。いっぽうでソースレベルでのデバッグには対応 していないため、状況に応じて利用するデバッガを選択するのが好ましいようだ。

　「Memory compaction」と呼ばれる、メモリの断片化を軽減する仕組みも追加された。これは使用中のメモリページを連続した大きなページに移動することでメ モリ使用効率の改善を図るというもの。ページ確保に失敗した際に実行されるほか、「/proc/sys/compact_memory」や「/sys /devices/system/node/nodeN/compact」に任意の値を書き込むことで任意のタイミングで実行させることもできる。

　グラフィック関連の改良点としては、IntelのG45チップセットなどが備えるH.264およびVC1デコードのハードウェアアクセラレーショ ン機能サポートや、2011年にリリースされると見られているIntelの新チップセット（Cougarpoint）サポート、Radeonドライバの各 種改良などが挙げられる。

　そのほかの主要な新機能としては下記が挙げられる。

• Btrfsでファイルシステムのキャッシュを通さずに直接I/Oを行う「Direct I/O」をサポート
• perfコマンドの改良
• multiple multicast route tablesのサポート
• L2TP Version 3（RFC 3931）のサポート
• CAIFプロトコルのサポート
• ACPI Platform Error Interfaceのサポート

　Linuxカーネル2.6.35はThe Linux Kernel Archivesやミラーサーバーなどから入手できる。

Linuxカーネル2.6.35リリース、ネットワーク負荷軽減機構やH.264ハードウェアデコードなどをサポート - SourceForge.JP Magazine : オープンソースの話題満載

このkernelがCentOSで使えるようになるのはいつになることやら。

1年前 | 固定リンク | 2010年 10月 15日 |

2010年 10月 4日

実践編

　コマンドをうまく組み合わせれば、あたながその内容を全く知らないパソコンの前に立って、GRUBのプロンプトを見たときでも、そのパソコンにインストールされているLinuxを起動させてしまうことができる。次のような手順である。

　まずはとにかく接続ハードディスクとパーティションを確認しよう。これは「root (」と入力してTABキーだった。
　

grub> root ( 　Pssibile disks are:  fd0  hd0  hd1  grub> root (hd0, 　Pssibile partitions are: 　　Partition num 0,  Filesystem type is ext2fs, partition type 0x83 　　Partition num 4,  Filesystem type is ext2fs, partition type 0x83 　　Partition num 6,  Filesystem type is ext2fs, partition type 0x83 　　Partition num 7,  Filesystem type is unknown, partition type 0x82

　沢山Linux Native(ext2fs)のパーティションがある。この中のどこかにカーネルがあるはずである。適当にあたりをつけて、ファイルを探してみる。どうせLinuxのカーネルなど、ルートか/bootにvmlinuzか何かの名前で存在しているに決まっているから、/vmlinzあたりで、探して見よう。
　

GRUB version 0.5.96.1 (640k lower / 3072k upper memory)  [Minimal BASH-like line editiing is supported. For the first word, TAB   lists possible command completion. Anywhere else TAB lists the possible   completions of a device/filename. ]  grub> find /boot/vmlinuz 　  Error 15: File not found  grub> find /vmlinuz   (hd0,0)

　/boot/vmlinuzでは見つからなかったが、「/vmlinuz」はあった。早速このパーティション(hd0,0)「/dev/hda1」をルートに指定して（これにより、そのパーティションに移動したイメージとなる）、更にルートディレクトリのファイルを見てみる。
　

grub> root (hd0,0)    Filesystem type is ext2fs, partition type 0x83  grub> find /    Possible files are: vmlinux-2.2.13-33 vmlinuz-2.2.13-33 vmlinuz initrd boot.b   chain.b os2_d.b boot.0200 boot.0308

　ルートコマンドで、そのパーティションが確かにext2fs（Linux Native）であることも確認できた。「find /」のあとTABを打てば、/ディレクトリ配下のファイルを表示してくれる。ちょっとしたlsコマンドの役目を果たすという訳だ。

　いろんなファイルが見つかったが、カーネルは「vmlinuz」で良さそうだ。きっとvmlinuz-2.2.13-33にシンボリックリンクが張ってあるのだろう。initrdもあるからRAMディスクも指定する必要があることも分かる。

　次にルートパーティションを調べる必要がある。このパーティションが「(hd0,0)」であることから、ルートパーティションは「/dev/hda1」である可能性もあるが、昔からの習慣でカーネルをルートパーティションとは別のパーティションに置き、このブート用のパーティションを/bootとしてマウントしている可能性がある。それにルートパーティションは、SCSIハードディスクやセカンダリのハードディスクだという可能性もある。「cat」コマンドで「/etc/fstab」を確認しよう。
　

grub> cat /etc/fstab 　  Error 15: File not found  grub> find /etc  Error 15: File not found

　「/etc」ディレクトリすら見つからない。やはりこのパーティション(hd0,0)「/dev/hda1」はルートパーティションではないようである。では、findで「/etc/fstab」を探しよう。
　　

grub> find /etc/fstab   (hd0,4)

　(hd0,4)「/dev/hda5」にあった。一応このパーティションに移って、/etc/fstabの内容を確認しよう。
　

grub> root (hd0,4)   Filesystem type is ext2fs, partition type 0x83 　  grub> cat /etc/fstab 　/dev/hda5          /                        ext2     default         1   1 　/dev/hda1          /boot                  ext2     default         1   1 　/dev/hda6          /usr                    ext2     default         1   1 　/dev/hda7          /home                 ext2     default         1   1 　/dev/fd0           /mnt/floppy          ext2     noauto,users  0  0

　間違いない。ルートパーティションは/bootとは別のパーティションだ。さすがに「etc」ディレクトリは、別のパーティションにマウントはされていないようなので、/etc/fstabが見つかったこのパーティション(hd0,4)「/dev/hda5」が、ルートパーティションであることは間違いないようである。

　これでカーネル、ルートパーティション、初期RAMディスクの位置を確認できたので当該Linuxを起動できる。

　尚、ここで誤解されがちなのだが、ルートからみた場合、カーネルは/boot/vmlinuzなのだが、これはあくまで/dev/hda5パーティションをルートパーティションの/bootにマウントしているためにこう見えるのであって、/dev/hda5パーティション上ではあくまでファイルシステムのルートにこの「vmlinuz」は存在する。

　従って、GRUBのカーネル指定では、root指定したパーティションのファイルシステム上で見える形、つまり、この場合は「/boot/vmlinuz」ではなく、「/vmlinuz」と指定する。initrdも同様である。

　では、早速カーネルのあるパーティションにrootコマンドで戻って、起動してみよう。
　

grub> root (hd0,0)    Filesystem type is ext2fs, partition type 0x83  grub> kernel /vmlinuz root=/dev/hda5    [Linux-bzImage, setup=0xe00, size=0xa09e0]  grub> initrd /initrd    [Linux-initrd @ 0x7078000, 0x177000 bytes]

　カーネルのロードも初期RAMディスクのロードもうまくいったようである。尚カーネルなどの指定は、直接パーティションも指定すれば、rootコマンドでそのパーティションを指定する必要はない。その場合、以下のような指定になる。
　

grub> kernel (hd0,0)/vmlinuz root=/dev/hda5    [Linux-bzImage, setup=0xe00, size=0xa09e0]  grub> initrd (hd0,0)/initrd    [Linux-initrd @ 0x7078000, 0x177000 bytes]

　
　さあ、後はもうブートするだけだね。最後に「boot」コマンドを叩く。
　　

grub> boot 　　　　・ 　　ブートメッセージ 　　　　・ 　　　　・

　うまくLinuxが起動したらご喝采！！

　同じような手法で、他のOSも起動できてしまう。Windows系のOSは特にカーネルなどの指定もないので、もっと簡単に起動できてしまうだろう。

　こんな芸当ができるブートローダはGRUBをおいて他にはないだろう。

GRUBのセットアップ

もしkernelが見つからないため起動できない的なエラーが起こってしまったら、落ち着いてこの対処をすれば起動するようになります。

1年前 | 固定リンク | 2010年 10月 4日 |