Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
2012 年 7 月 1 日のうるう秒挿入時に発生した Linux カーネルの不具合に関する情報
更新履歴 2012-08-28: URL 公開 2012-08-29: futex、hrtimer、MySQL の発生条件、NTP SLEW モードに関する @odhrfm さんからの情報、キーワード更新、その他いろいろ細かい修正 2012-08-30: 参考リンク追加 2012-09-01: LKML まとめシートの thread#50 を追加 2012-09-03: SLES カーネルの更新情報、per-cpu についての記述、blockdiag によるブロック図を追加 2012-09-11: LKML まとめシートの thread#52, #53 を追加 2012-09-12: LKML まとめシートの thread#54 〜 #58 を追加 はじめに 日本時間 2012 年 7 月 1 日 9:00 にうるう秒が挿入されましたが、その際 Linux カーネルに起因する不具合により、
よくわかるLinux帯域制限 | GREE Engineering
矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日本語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が
ChatOpsでOSのセキュリティアップデートを自動化出来るようにした - Glide Note
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
Kernel Line Tracing: Linux perf Rides the Rocket
Recent posts: 24 Mar 2024 » Linux Crisis Tools 17 Mar 2024 » The Return of the Frame Pointers 10 Mar 2024 » eBPF Documentary 28 Apr 2023 » eBPF Observability Tools Are Not Security Tools 01 Mar 2023 » USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon 17 Feb 2023 » USENIX SREcon APAC 2023: CFP 02 May 2022 » Brendan@Intel.com 15 Apr 2022 » Netflix End of Series 1 09 Apr 2022 » Te
fork()は失敗するんだぜ、覚えときな
fork() can fail: this is important あー、fork()のことね。プロセスがもっとプロセス作るためのやつな。いや、他にもプロセス作る方法はあるけどな。ま、面白い話がもうひとつあるから聞かせてやるよ。 forkは失敗するんだぜ。分かってるか？ マジで分かってるか？ マジだぜ。forkは失敗するもんだ。mallocと同じさ。失敗することもある。そんなに頻繁にってわけじゃないけどさ、でも失敗したら、無視できっこないぜ。ちっとは脳みそ働かせなきゃならん。 forkが0を返したら、そいつは子プロセスで、親なら正数を返すってことは、みんな知ってるよな。その値は子のpidだ。こいつを保存しといて、あとで使うってわけだ。 失敗を確認しない場合どうなるか知ってるか？ そうだよ。お前多分、"-1"（forkのエラー通知）をpidとして扱ってるんだろ。 さて、問題の始まりだ。本当
Bug #248619 “file incorrectly labeled as Erlang JAM file (OOo do...” : Bugs : file package : Ubuntu
Binary package hint: file anon@x-X:~$ echo "1/2 Tue" >> file && file file file: Jan 22 14:32:44 MET 1991\011Erlang JAM file - version 4.2 anon@x-X:~$ file --version file-4.21 magic file from /etc/magic:/usr/share/file/magic If you look at the magic file: 4 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2 So at the fourth byte of the file, it's looking for Tue Jan 22 14:32:44 MET 1
Linuxで、どのプロセスがページングを行っているのか調べるには？ | Yakst
スワップがなぜ起きるか、どのようにスワップの状態を確認するべきかの平易な解説。Quoraの質問に対する、Robert Love氏の回答。 質問に対するストレートな回答は、調べるのは不可能、だ。どうしてそうなのかを説明してから、君の知りたい情報を含んでいるであろう、5つの関連する質問に答えよう。 Linuxのような、モダンなOSにおいては、スワップはシステム全体における現象だ。ある1つのプロセスがスワップに関する責任を持っているわけではない。システムがスワップしているかどうかは、メモリプレッシャの機能による。物理メモリを大量に使おうとすれば、スワップしてしまう。何をスワップアウトするかは、一番少ないページを要求しているのが何かによる。何をスワップインするかは、一番ページを必要としているのが何かによる。プロセスがRAM上に存在しないページを要求した時、そのページはディスク上にあるので、スワップ
CentOS 7 がリリースされたので、情報をまとめてみたよ！
CentOS の新しいメジャーリリース、 CentOS 7がリリースされました！ お断り：ここの情報は非公式なもので、ベストエフォートで提供されています。 国内ミラー状況 公式サイトには掲載されていませんが、国内の有力ミラーサイトがすでにミラーを終えています。 http://ftp.iij.ad.jp/pub/linux/centos/7/ http://ftp.ne.jp/Linux/distributions/CentOS/7/ http://ftp.riken.jp/Linux/centos/7/ http://ftp.jaist.ac.jp/pub/Linux/CentOS/7/ バージョン番号の変更 今回からバージョン番号が 7.0-1406、というように、末尾に数字がつくようになりました。 7.0 は upstream である Red Hat Enterprise Linux
[CentOS-announce] Release for CentOS-7 on x86_64
Karanbir Singh kbsingh at centos.org Mon Jul 7 18:30:23 UTC 2014 Previous message: [CentOS-announce] CEBA-2014:0828 CentOS 6 nfs-utils Update Next message: [CentOS-announce] CentOS 7 Release - Zero Day Updates Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We would like to announce the general availability of CentOS Linux 7 for 64 bit x
sshによるユーザ列挙攻撃"osueta" - ろば電子が詰まつてゐる
ものすごく遅いレポートですが、先日、ゆるふわ勉強会こと さしみjp ささみjpの#ssmjp 2014/06 に参加させて頂きました。 この中で、@togakushiさんの発表「OpenSSH User EnumerationTime-Based Attack と Python-paramiko」が面白かったのでそのメモです。 osuetaとは何か OpenSSHでは、パスワード認証の際に長い文字列(目安で数万文字)を与えると、存在するユーザと存在しないユーザの場合で応答速度が変わってきます。環境によりこの時間差は結構違うようですが、私の試した範囲では、 存在するユーザの場合は数十秒 存在しないユーザの場合は数秒 で応答が返りました(この応答速度は目安です、もちろんマシンスペックによって違うでしょう)。これにより、複数のユーザでsshログイン試行をおこない、その応答時間を計測することでユー
Getting Started with RHEL7 | blog-kazuhisya.rhcloud.com
Red Hat Enterprise Linux 7 リリース おめでとうございました。Docker をはじめ最新のテクノロジーを詰め込んだとだけあって、メジャーリリースに相応しい出来栄えのようですね。 systemd などは upstream の Fedora では 3年くらい前の fc15 くらいからですし、慣れてる人も多いでしょうが el7 で初めて触る人は結構辛いでしょうね。 とりあえず細かい話は公式のドキュメント類を目を皿にして読んでもらうとして、el6 までしか触ったことない人が真っ先に躓きそうなポイントを挙げてみます。Docker とか SDN とか目新しいことも大事だけど、基本的なことを当たり前にやってのけられる様になることがまずは重要かな、と。 作業の前に bash-completion パッケージを導入することを強くおすすめする。なお、minimal だと入っていなかっ
「GnuTLS」に新たな脆弱性、主要Linuxディストリビューションに影響
悪用された場合、GnuTLSを使っているTLS/SSLクライアントで任意のコードを実行される恐れもある。 Red Hat、Debian、Ubuntuなどの主要Linuxディストリビューションに使われているオープンソースのSSL／TLSライブラリ「GnuTLS」に新たな脆弱性が見つかり、修正パッチがリリースされた。悪用された場合、クライアントサイドで任意のコードを実行される可能性が指摘されている。 Red Hatが公開したセキュリティ情報によれば、この脆弱性に関する情報は5月28日に公開され、6月3日までに修正パッチが公開された。GnuTLSでTLS/SSLハンドシェイクのServer HelloパケットからのセッションIDを解析する方法に脆弱性があり、不正なサーバを使って過度に長いセッションIDを送り付けることにより、GnuTLS経由で接続しているTLS/SSLクライアントをバッファオーバ
サーバーさんに本気を出してもらうために憶えておきたい設定項目
cpuspeed がオンだと.... — はせがワン (@hasegaw) 2014, 5月 29 ミドルウェアのスループットを測ろうと思ったのですが cpuspeed などの設定をぜんぜんやっていませんでした。。。 経験上、チューニング過程でいじりたくなるようなパラメータを思い出してみます。 パワーマネジメントに関する設定はオフにする UEFIやBIOSにはパワーマネジメント設定がありますが、これらを無効にするとプロセッサなどが無条件で定格クロックで走り続けます。ピーク性能を高めたり瞬発力を上げるためにはパワーマネジメントはオフにします。当然ながらベースの消費電力やファンの騒音は増えますが、かわりにいくらかピーク性能の向上が見込めます。 Hyper Threading はレイテンシーとスループットのトレードオフ Hyper Threadingは、たぶん、コア内でパイプラインを取り合うから
Dockerを支える技術
5. Open Cloud Campus 5 Linux女子部 Dockerを支える技術 一般的なサーバ仮想化の分類 物理マシン 物理マシン ホスト OS ハイパーバイザ （カーネルモジュール） 仮想 マシン ゲスト OS VMware vSphere, Xen など Linux KVM ハードウェアによる仮想化 （物理マシンにハイパーバイザを内蔵） ソフトウェアによる仮想化 （物理マシン上にハイパーバイザを導入） ソフトウェアによる仮想化 （ホスト OS にハイパーバイザ機能を追加） 物理マシン OS 非仮想化環境 基本的には「物理マシン」と同等の「仮想マシン」を複数 作り出す技術です。 仮想 マシン ゲスト OS 仮想 マシン ゲスト OS 仮想 マシン ゲスト OS 仮想 マシン ゲスト OS 仮想 マシン ゲスト OS 仮想 マシン ゲスト OS 仮想 マシン ゲスト OS ハイパ
Ceph の開発元の InkTank 社が Red Hat に買収される - 教育は参考ブログ
Red Hat のプレス | Red Hat to Acquire Inktank, Provider of Ceph The Ceph Blog | Red Hat to acquire Inktank TechCrunch | Red Hat Buys Inktank For $175M In Cash To Beef Up Its Cloud Storage Offerings Slashdot | Red Hat Acquires InkTank, Ceph Maintainers The Register | Red Hat snaps a Ceph-ie: Upstart Inktank gobbled for $175m Red Hat が Ceph の開発元である InkTank 社を 1.75 億ドルで買収されたという驚くべきニュースが流れている。OpenStack に積
OOM relation to vm.swappiness=0 in new kernel
I have recently been involved in diagnosing the reasons behind OOM invocation that would kill the MySQL server process. Of course these servers were primarily running MySQL. As such the MySQL server process was the one with the largest amount of memory allocated. But the strange thing was that in all the cases, there was no swapping activity seen and there were enough pages in the page cache. Iron
クラウドコンピューティングと負荷分散ソリューションLVS 第1回: LVSのアーキテクチャ | 技術文書 | 技術情報 | VA Linux Systems Japan株式会社
クラウド 負荷分散 クラウドコンピューティングと負荷分散ソリューションLVS 第1回: LVSのアーキテクチャ 2012/07/25 技術本部 本部長 高橋 浩和 Linux Virtual Sever (LVS)は、Linuxオペレーションシステム上で実行されている負荷分散ソリューションの一種で、1998年5月、Wensong ZhangによってOSSプロジェクトとして開始されました。 LVSは、実サーバのクラスタ上に構築されたコンピュータ・クラスター技術を用いて高性能かつ高可用なLinuxサーバを構築し、スケーラビリティや信頼性、保守性を向上させます。また、LVSを利用することで、Webサービスや電子メールサービス、メルチメディア、VoIPサービスなどの高信頼ネットワークサービスの構築が可能となります。 VA LinuxはLVSに積極的な貢献をしており、新機能の実装や現バージョンへの移
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
宁波逼拘旅行社
VMware KB: Linux ゲストの時刻管理のベスト プラクティス