RustでLinuxカーネルモジュールを実装しようと張り切ってきましたが、カーネルがサポートする大半のCPUアーキテクチャでRustは使えません。Rustの公式コンパイラがサポートするアーキテクチャが少なすぎるので、別のRustコンパイラを試してみました。
Things will never be the same again after the dust settles. And yes, I’m talking about Linux. As I write this, most of the world is in lockdown due to COVID-19. It’s hard to say how things will look when this is over (it will be over, right?), but one thing is for sure: the world is no longer the same. It’s a weird feeling: it’s as if we ended 2019 in one planet and started 2020 in another. While
This topic describes common Linux kernel network parameters of Elastic Compute Service (ECS) instances. This topic also provides answers to frequently asked questions about the Linux kernel network parameters. ConsiderationsBefore you modify kernel parameters, take note of the following items: We recommend that you modify kernel parameters based only on your business requirements and relevant data
背景システムの処理速度を改善するために、ボトルネック解析を行う必要があった。 ボトルネック解析の方法と、プロファイリングに使用したperfの使用方法に関して調査を行った。 記事の目的perfを使用し、ボトルネック解析を行う ここでは、perfの導入方法及び使用方法について記載する。 perfとはperf(Performance analysis tools for Linux)とはLinuxカーネル2.6.31以降で使用可能なLinuxの性能解析ツールである。 実行されているプロセス毎のCPU使用率やプロセス内で呼ばれている関数の割合などを調査できる。 利点gprofのように、プログラム作成時に専用のライブラリを入れたり、コンパイル時にオプションをつける必要がない フレームグラフにして、ビジュアライズできる 導入方法(Ubuntu編)Ubuntu16.04へperfを導入する手順について記
1.はじめに ネットワークのパフォーマンスを決定付ける最も重要な要素は、最終的にはアプリケーションにあるでしょう。ただ、ワークロードの特性によっては、デフォルト設定されたTCPカーネルパラメータが制約となり、パフォーマンスを発揮できないときもありますね。 非常にたくさんのカーネルパラメータがありますが、本文では、ネットワーク帯域幅(bandwidth)のカーネルパラメータ、ネットワーク容量(capacity)のカーネルパラメータを主に扱います。 2.準備 Linuxはsysctlコマンドで簡単にカーネルパラメータを実行時に変更できます。 次のようなコマンドを使用すると、現在のカーネルパラメータ設定値の全体を閲覧できます。 $ sysctl -a ここで取り上げるネットワークは、特にTCPのcapacityとbandwidthなどを調整(tuning)できるカーネルパラメータのごく一部を紹介
はじめに (本記事は Linux Advent Calendar 2020 および 東京大学 品川研究室 Advent Calendar 2020の11日目の記事として書かれました。) カーネルのビルドについての情報はググると色々と出てきますが、「ここを見ればOK」と思えるサイトに巡り会えていないので、自分で書いてみることにしたのが本記事です。 いずれLinuxカーネルをビルドする必要にかられるであろう研究室・学科の後輩や、忘れっぽい将来の自分のためにも、改めてLinuxカーネルのビルド方法についてまとめてみたいと思います。 概要 さて、「カーネルをビルドしよう」という状況に置かれた場合、実際にすべきことは主に以下の4点だと思います。 ソースコードの取得 ビルド環境の構築 カーネルコンフィグの準備 ビルド及びインストール そこで本記事では、カーネル本体のビルド上記の4点の他、関連して以下の
Linux OS でキャッシュをクリアする方法 (Kernel 2.6.16〜) 性能の試験をするときにファイルシステムのキャッシュによる影響を排除する。 root もしくはスーパーユーザーコマンドにて行なう。 % su root or sudo # sync # sysctl -w vm.drop_caches=1 # sysctl -w vm.drop_caches=2 # sysctl -w vm.drop_caches=3 or # echo 1 > /proc/sys/vm/drop_caches # echo 2 > /proc/sys/vm/drop_caches # echo 3 > /proc/sys/vm/drop_caches 1 … ページキャッシュのクリア 2 … ディレクトリエントリー(dentry)と inode のクリア 3 … ページキャッシュおよびディレ
こんにちは!@kakeyangです! 久しぶりの投稿です。 なぜなら、、、沖縄の八重山諸島に旅行に行ってましたのです! 楽しかったなぁ(遠い目) 今回は、開発で経験した通信障害の原因とその対策を公開します。 原因がLinuxカーネルの設定だったので、結構苦労しました。。。 障害概要 異なるネットワーク内(片方は弊社ネットワーク)の物理サーバ間(弊社が受信側)でインターネット越しにソケット通信を行う。 毎回ではないが1割程度の割合で、送信側でconnection timeoutを観測。 受信側にはapacheのログが残っていなかったので、webサーバには届いていない。 送信側でtracerouteすると、確かに弊社ネットワーク内には入っている。 弊社ネットワーク内のF/Wから物理サーバの間のどこかで通信が途絶えているっぽい! というところまではすぐに判明しました。 調査内容 データセンターと
Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード/ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう(というかできません)。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ
3. 自己紹介 - まぁまぁ MySQL でご飯食べてます - 一時期は Resource Monitoring や KVS にも 力入れてました - ネットワーク的には素人です - Linuxとハードウェアは嗜む程度 - disk I/O にはむかしから興味あります - その他 slideshare はこちら - http://www.slideshare.net/takanorisejima/ 4. 本日のお題 - kernel 新しくしたりすると、TCP的に意識したほ うが良い変化が見つかるので - 今日は、Webアプリケーションサーバの観点か ら、 connect(2) する際に気になる TIME_WAIT について、書いてみようかと思います - 有識者からのマサカリを、強く歓迎いたします 5. 最初に参考資料 - この二つの記事を読んでいただけば、それで概 ね良いと思うんですが
数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール/SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上
Linuxのカーネルは膨大な数のソースコードから成り立っており、どこに何の処理が書いてあるのかぱっと見当をつけるのにはかなりコードを読み込む必要があります。「Interactive map of Linux kernel」はそのソースコードを機能とレイヤーで分類して表示してくれるサイトということで、使い勝手を試してみました。 Interactive map of Linux kernel http://www.makelinux.net/kernel_map/ サイトにアクセスし、ロードが終わると下の画像のように6列6行の表が表示されます。列が機能の分類を表しており、「インターフェース」「システム」「処理」「メモリー」「ストレージ」「ネットワーク」という分類になっています。行はレイヤーを表しており、上からシステムコールなどの「ユーザースペースインターフェース」、「バーチャル」、「ブリッジ」
linuxサーバのOS全体に効くカーネルパラメータのチューニング箇所と その設定値、またその理由をまとめておく。 あくまで自分の環境ではこうした、というだけであり、 提供するサービスごとに検討が必要である。 どこをどう変更するのか、または変えないのか、その判断材料にはなるだろう。 ※ユーザ単位でシステムリソースに制限をかける場合をこちらを参照してほしい。 以下は/etc/sysctl.conf で設定するものとする。 ● 大規模サイト用チューニング kernel.pid_max 動作:pidの最大数 設定値:131072 理由:pidを枯渇させない vm.max_map_count 動作:mmapやmalloc時にメモリを仮想空間にマッピングできる最大ページ数 設定値:300000 理由:マッピングできなくなる事態を防ぐ net.core.somaxconn 動作:接続(ソケット)キューの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く