環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
この記事は Akatsuki Advent Calendar 2019 1日目の記事です。 はじめに アカツキでは Ruby on Rails を使ったゲームサーバを開発・運用しています。ゲームの体験を向上するために、レスポンスタイムは一つの重要な要素となるため、種々のパフォーマンスチューニングを行なっています。今回はその一例として、環境変数を1つ設定するだけで、あるAPIのレスポンスタイムが10%も改善した例をご紹介します。 TL;DR 多数の時刻を含むレコードを扱う Ruby on Rails サーバでは、 TZ 環境変数を設定することで、デフォルトタイムゾーン設定ファイル /etc/localtime へのアクセスが減り、高速化が図れるかもしれません。 効果は Time オブジェクト1個あたり数μsの短縮といったオーダーですが、チリも積もれば山となり、数千個のレコードを処理するAPI
Supporting Linux kernel development in Rust
This article brought to you by LWN subscribersSubscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible. The Rust programming language has long aimed to be a suitable replacement for C in operating-system kernel development. As Rust has matured, many developers have exp
Linux Networking Tools: 101
Representation Learning for Scale-free Networks: スケールフリーネットワークに対する表現学習
SCOによる対IBM訴訟に関するOSIのポジションペーパー
目次 はじめに 本ペーパーで取り上げる内容 歴史と技術的な背景 「UNIX」の意味 Linuxとオープンソース・プログラミングの到来 Bell Labsコードベース 争点のUNIX派生物間の関係 各社の歴史 オープンソースに関するSCOの歴史 「エンタープライズ・スケーラビリティ」の意味 SCO/Calderaはその歴史と立場を偽っている SCO/Calderaが重要な企業であったという主張は偽りである SCO/Calderaが唯一のIntel UNIXベンダだったという主張は偽りである SCO/CalderaはUNIXに対する権利の範囲を偽っている SCO/CalderaのUNIXスケーラビリティ技術を所有しているという主張には説得力がない SCO/Calderaは自身の役割を無視して、開発の動機付けを行うどころか、それを非難してはばからない SCO/Calderaは不正な表現でオープン
リンカ
ついに、リンカの説明をするときが来た。 ここに至るまでに、何度「リンカのところで説明する」と書いただろうか？ ここまで読んできた人ならば、 リンカというものが、なにやら色々やっているんだな、というのはわかってきたのではないかと思う。 筆者が常々思っていることのひとつに、「C言語に関する書籍は、リンカの説明をおざなりにしすぎだ」というのがある。 多くのC言語の書籍は、 コンパイラがソースコードをアセンブリコードに変換します アセンブラがアセンブリコードを機械語に変換します リンカが機械語をリンクして実行ファイルが作られます と、いう解説がなされがちである。この説明を見たら、多くの人が、「え、リンクってなんですか？」と、思うに違いない。 アセンブラには、「人間が読めるニーモニックを、機械が読める機械語に変換する」みたいな、最低限の説明が付くものの、 リンカの説明は「リンクをします」のひとことだ
会社のテックブログに記事を書きました: ペパボ トラブルシュート伝 - TCP: out of memory -- consider tuning tcp_mem の dmesg から辿る 詳解 Linux net.ipv4.tcp_mem - hibomaの日記
以下の記事です。 tech.pepabo.com TCP our of memory memory pressure モード net.ipv4.tcp_mem 以上の三つの詳細を扱ったエントリです。TCP で大規模なトラフィックを扱っているサーバを扱われている場合、問題がないかどうかを確かめてみるとよいかと思います。 本文長いです。何に気をつけたらいいんでしょう? プラクティカルな話だけをまとめると、以下の4行です。 memory pressure モードに入ってしまうと warning です TCP out of memory が出てしまうと critical です 監視は /proc/ 以下のファイルを見ましょう チューニングは net.ipv4.tcp_mem で行いましょう LVS はどうなの? LVS でロードバランシングしている場合は、TCP スタックを通らないため TCP o
Amazon Linux2(systemd)のプロセス数やファイルディスクリプタ数を変更する
今回はAmazon Linux から Amazon Linux2 への移行をする機会があったので、 プロセス数やファイルディスクリプタ数といったリソース制限の変更に関して備忘録として残しておきます。 なお、以降の手順は公式の Amazon Linux2 のAMIをそのままブートした後に試しています。 ソフトリミットとハードリミットまず、最初によく聞くソフトリミットとハードリミットの確認しましょう。 Linuxではユーザやプロセスごとに利用できるリソースを制限することできます。 これらには ソフトリミット と ハードリミット の2種類が存在します。 ソフトリミットはユーザの現在の設定値を指し、ハードリミットはユーザ側での変更可能なソフトリミットの上限値を意味します。 ログインユーザへの設定limits.confを書き換えるLinuxへのログインユーザへの設定は /etc/security/l
CPU律速なRuby/Pythonコードはデフォルト設定のdocker上で遅くなる - まめめも
English version 要約 dockerはデフォルトでセキュリティ機構（Spectre脆弱性の対策）を有効にします。この影響で、RubyやPythonのようなインタプリタは速度が劣化します。特にCPU律速なプログラムで顕著に遅くなります（実行時間が倍くらいになることがあります）。 現象 Rubyで1億回ループするコードを、直接ホスト上で実行する場合と、docker上で実行する場合で実行時間を比較してみます。 直接ホスト上で実行した場合： $ ruby -ve 't = Time.now; i=0;while i<100_000_000;i+=1;end; puts "#{ Time.now - t } sec"' ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] 1.321703922 sec docker
Memory part 2: CPU caches [LWN.net]
Benefits for LWN subscribersThe primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today! [Editor's note: This is the second installment in Ulrich Drepper's "What every programmer should know about memory" document. Those who have not read the
マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー
また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ
Linux containers in a few lines of code
This post is meant to be a counterpart to the previous KVM post, but about containers instead. The idea is to show how exactly containers work by running a busybox Docker image in our own small container runner. Unlike a VM, container is very vague term. Normally, we call containers a self-contained bundle of code and its dependencies, that can be shipped together and run in an isolated environmen
Linux / x86_64の割り込み処理 第1回 | 技術文書 | 技術情報 | VA Linux Systems Japan株式会社
「割り込み処理」とは、読んで字のごとく、通常の流れでプログラムを実行している所へ割り込んで別のプログラムを実行させることです。通常は、周辺デバイスなどからのイベント通知に使われるハードウェア割り込みを指しますので、本稿でも以下その意味で使います。 Linuxに限らず、現在一般的なOSでは、ディスクやマウスなどのデバイス入出力の他、タスクの切り替えや定時処理などさまざまな場面で割り込み機能を駆使して作られています。 ところで、現在一般的なPC/PCサーバは、IBM PCやIBM PC/AT以来約30年間、互換性を保ちながら発展してきたものであり、こと割り込みまわりに関しては、たいへんに複雑です。これを制御するLinuxも、この複雑さに対応するために、複雑な作りになっています。 本稿では、この複雑なLinuxの割り込み処理の低レイヤ (もっともハードウェアに近い部分) について解説していきます
メモリダンプと模様が見える男｜kamezawa.hiroyuki｜note
10年以上前の昔話であり、そんなこともあったのねという話。あるいはエンタープライズサポートってそんなことやってるのねという話。 カーネルメモリダンプLinuxカーネルをエンタープライズに使おうとした企業、富士通やIBM、日立といった企業がこぞってカーネルに入れようとした機能がカーネルがパニックした時に「なぜコケたのか」調べるための機能であった。その最たるものがメモリダンプだった。この機能はカーネルパニックが起きた後のメモリをディスクに吐き出す。この吐き出されたメモリイメージをダンプと呼び、これをデバッガに食わせて原因調査をする。 カーネルデベロッパはパニックが起きたら再現条件を探して理詰めでバグを探すのが得意だが、顧客先でパニックが起きたら「再現させてくれ」とは中々言えないのでこの機能はサポートには重要だった。そして、ダンプ調査の技を持つエンジニアも居た。 地雷型メモリ破壊パニック色々と調
dockerでvolumeをマウントしたときのファイルのowner問題 - Qiita
dockerでvolumeをマウントするときの問題点 docker runするときに-vオプションをつけることによってホストのディレクトリをコンテナ内にマウントすることができる。 ホスト側のファイルをコンテナ内で使いたい場合や、逆にコンテナで作ったファイルにホストからアクセスしたい場合に有用なのだが、ファイルのアクセス権限についてちゃんと考えておかないと問題が起きることがある。 例えば、ホスト内でのユーザーのuidが500だったとしよう。 $ id uid=500(ec2-user) gid=500(ec2-user) groups=500(ec2-user),10(wheel),497(docker) $ mkdir -p temp && touch temp/foo # 実験用に適当なディレクトリを作ってみる $ docker run -it -v $(pwd)/temp:/temp
linuxカーネルに関する独自コードをメンテナンスするコスト - Qiita
はじめに Linuxカーネル(以下カーネル)に機能を追加する、あるいはバグを修正する自作コードには次の2つの種類があります。 独自カーネルモジュールの作成 カーネル本体の変更 これらの変更を長期間メンテナンスするには次の方法があります。 Linux開発コミュニティに働きかけて独自コードを公式のmainlineと呼ばれるツリーにコードをマージする 独自コードを自分自身で管理して、mainlineカーネルの新バージョンが出るたびに追従する(後述) 本記事は前者の方法に比べて後者の方法をとった場合に必要なメンテナンスコストについて述べます。本記事の表題にはlinuxと書いていますが、linuxと似たようなドラスティックな変更(後述)を是とするソフトウェアすべてに当てはまる話なのでlinuxの開発には関係ないかたにも役立つ話かと思います。 独自カーネルモジュールを作る場合の追従コスト 昨日書いたエ
2020年1月10日 Don't use ZFS ―Linus、ZFSをマージしない姿勢をあらためて強調 | gihyo.jp
Linux Daily Topics 2020年1月10日Don't use ZFS ―Linus、ZFSをマージしない姿勢をあらためて強調 「Don't use ZFS. ―ZFSは使わない。その理由はシンプルだ。ZFSはこれまでずっと、バズワード以上の何物でもなく、そして実感するのだけど、例のライセンシング問題は僕にとってZFSを価値のない存在と思わせるだけだ」 1月6日、IT業界に特化したオンラインメディア「Real World Tech」のフォーラムで繰り広げられたあるスレッドにて、Linus TorvaldsはZFSをメインラインにマージする予定がないことをあらためて明確に主張している。 Do not blame anyone. Please give polite, constructive criticism By: Linus Torvalds -Real World Te
perfから読み解くプロセッサトレースの仕組み (perf + Intel PT/ARM CoreSight) - Qiita
諸事情でperfのソースコードを読んだのでせっかくなので簡単に解説。 今回はperfの中でもイベントの記録を担当するperf recordコマンドの処理を見ていく。特に近年はCPUがトレース機構を持っておりperfもその恩恵に預かっているため、本記事ではperf recordの中でもCPUのプロセッサトレース機構との連携部分に注目したい。 本音を言えば、perfよりIntel Processor Trace(Intel PT)やARM CoreSightといったプロセッサトレース自体に興味があるのだが、これらはLinux上ではperfイベントとして実装されているためperfコマンドの実装を皮切りに解析する腹づもりだ。 1. Perf アーキテクチャ 元々perfはPerformance counters for Linux (PCL)という名前の前身が存在しており、CPUの提供するパフォー
永続的なブロックデバイスの命名 - ArchWiki
永続的な命名の方法 永続的な命名には4つの異なる形式があります: by-label、by-uuid、by-id と by-path。GUID Partition Table (GPT) のディスクを使用する場合、さらに by-partlabel と by-partuuid の形式も利用可能です。また、udev による固定デバイス名を使うこともできます。 /dev/disk/ 内のディレクトリは、デバイスがあるかどうかに応じて動的に作成・破棄されます。 以下のセクションではこれらの異なる命名規則がどのようなものであるか、またどうやって使うのかを説明しています。 lsblk コマンドを使うことで1つ目の永続的な名前をグラフィカルに表示することができます: $ lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat CBB6-24F2
いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか？ を運用に生かす｜ハイクラス転職・求人情報サイト AMBI（アンビ）
いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか？ を運用に生かす Webアプリを動かして負荷をかけると、OSのプロセスという観点ではどのように見えるのでしょう？ それを通して運用やトラブルシューティングではどういったことが分かるのでしょう？ Linuxカーネルの開発者でもある武内覚（sat）さんによる解説です。 こんにちは、sat（@satoru_takeuchi）と申します。 コンピュータが誕生してから現在まで、最終的にエンドユーザが意識するアプリケーション開発はどんどん楽になっています。先人たちのたゆまぬ努力の結果、アプリ開発者はOSや、そのさらに下にあるハードウェアのことをほとんど意識することなく開発ができるようになりました。 しかし、「作ったアプリが、OSレベルでどのように動いているか？」が今一つピンと来なくて、モヤモヤしていないでしょうか。それ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
curl は何をしているか #システムコール編 - Qiita
