タグ

linuxとLinuxに関するsyossanのブックマーク (12)

  • NAT環境下では net.ipv4.tcp_timestamps = 0 する - かみぽわーる

    NAT環境下に複数ホストがいてそいつらがクライアントのときに、WAN側のサーバに接続が切られるときは net.ipv4.tcp_timestamps = 0 すればいいというのを教えてもらいました! 【緩募】SYN に SYN+ACK じゃないレスポンス受け取って RST しちゃう問題の解決方法 2011-04-01 19:06:11 via YoruFukurou @kamipo それポートが足りないとかネットワーク的に問題あるとかそういうなんじゃなくて? 2011-04-01 19:09:18 via Echofon to @kamipo @kamipo 防火壁かなんかで弾いてません? 2011-04-01 19:13:09 via TwitVim to @kamipo @mattn_jp iptablesでIPマスカレードしてるLinuxルータをgatewayにしてる環境なんですが、

  • GoogleのTCP BBRでTCPを高速化しProxyもその恩恵にあずかる - Qiita

    TCP BBR(以下BBRと略します)は、Googleが新しく開発したTCPを高速化するための輻輳(ふくそう)制御アルゴリズムです。 GitHub/google/bbrのプレゼン資料(PDF) Google Cloud Platform Japan 公式ブログ 上記資料にもある通り、YouTubeに採用した結果、一部の国でスループットを14%以上も引き上げた実績があるとの事なので、先日構築したProxy(Qiita記事)のサーバーへ導入してみる事にしました。 上記Qiitaの記事では、Shadowsocksという日では知名度の低い仕組みを採用していますが、SquidでProxyを構築している方やApacheでWebサーバを構築している方などにも、興味を持っていただけたら幸いです。 対象としている人 最低限のLinuxの知識がありテスト環境を構築できる人1 手軽に最新の技術に触れてみたい人

    GoogleのTCP BBRでTCPを高速化しProxyもその恩恵にあずかる - Qiita
  • TCPの輻輳制御アルゴリズム、どれが一番速い?

    TCPの重要な要素として、輻輳制御アルゴリズムがある。TCPはシーケンス番号を使った応答確認によってデータの確実な到達を担保している。応答確認が行われないパケットについては、再度同じデータを送信するように、受信側から送信側へ再送要求が行われる。 ところが、ネットワークが輻輳して遅延が大きくなると、同じデータを何度も再送してしまい、無駄なトラフィックが発生して輻輳がさらに悪化する。そこで転送量を制御して輻輳状態を抑える「輻輳制御」が重要となる。 輻輳制御を行うアルゴリズムの歴史は、TCPの歴史と言っても過言ではない。ここで簡単に発展経緯をひもといてみよう。 1988年に初登場した輻輳制御アルゴリズム「Tahoe」は、後に登場するアルゴリズムに多くの影響を与えた。段階的にウインドウサイズ▼を増加させて帯域流量を増加させる「スロースタート」、再送タイムアウトを待たずにパケットを送信する「高速再送

    TCPの輻輳制御アルゴリズム、どれが一番速い?
  • ファイルロック - Plan9日記

    UNIXでは複数のプロセスが同時にファイルにアクセスできるが、自動的にはロックされないので、おそらく最後のプロセスが書き込んだ結果が結果的に残こることになる。これでは都合が悪いので(特に分散ファイルシステムや分散OSでは)、ファイルロックという仕組みが提供されている。UNIXではflockやlockf、fcntlが使われる。UNIXのファイルロックは基的にアドバイザリロック(advisory lock)と言って、プログラムがお行儀よく書かれていることが前提になっている。一方、カーネルによって強制的にファイルアクセスを排他制御する仕組みを強制ロック(mandatory lock)と呼ぶ。 Plan 9には強制ロックを実現する仕組みとしてファイルパーミッションを拡張している。exclusive (l)ビットがそれである。 % touch a % chmod +l a % ls -l a -l

    ファイルロック - Plan9日記
  • Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;

    以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot

    Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
  • CPU / メモリ / ディスクに負荷をかける stress コマンド - kakakakakku blog

    最近 stress コマンドを使って,サーバに負荷をかける方法を紹介する機会があり,よく使っているのに今までブログに書いていなかったなと気付き,今回まとめることにした.CPU に負荷をかけるだけなら yes > /dev/null をコア数に合わせて並列実行すれば良いけど,stress コマンドならメモリとディスクにも負荷をかけることができるので,シナリオのバリエーションを増やすことができる. stress project page インストール 検証環境として CentOS を使った. $ sudo yum install stress $ stress --version stress 1.0.4 共通オプション 以下のような共通オプションが用意されている.よく使うのは --timeout で,秒数を指定して負荷をかけることができる.他はあまり使ったことがないかも. -t, --tim

    CPU / メモリ / ディスクに負荷をかける stress コマンド - kakakakakku blog
  • net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita

    Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 文中で Linux のコード/ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう(というかできません)。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ

    net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita
  • Linuxシステムコール徹底ガイド | POSTD

    要約 この記事では、LinuxカーネルにてLinuxプログラムがどのように関数を呼び出すのかについて紹介していきます。 システムコールを行う様々な方法、システムコールを行うための独自のアセンブリの作成方法(例あり)、システムコールへのカーネルエントリポイント、システムコールからのカーネルイグジットポイント、glibcのラッパ関数、バグなど多くの点について説明します。 要約 システムコールとは? 必要条件に関する情報 ハードウェアとソフトウェア ユーザプログラム、カーネル、CPUの特権レベル 割り込み モデル固有レジスタ(MSR) アセンブリコードでシステムコールを呼び出すことの問題点 レガシーシステムコール 独自のアセンブリを用いたレガシーシステムコールの使用 カーネル側での int $0x80 エントリポイント iret を使用したレガシーシステムコールからの復帰 高速システムコール 3

    Linuxシステムコール徹底ガイド | POSTD
  • Linux Kernel Document Wiki @ SF.jp

    トップページへ Linuxカーネルに関する技術情報を集めていくプロジェクトです。現在、Linuxカーネル2.6解読室の第2章までを公開中。 目次まえがき第0章 Linuxカーネルの構成要素 0.1 Linuxカーネルとは 0.2 Linuxカーネルのソースコード 0.3 Linuxカーネル機能の概要 0.4 カーネルプリミティブ 0.5 プロセス管理 0.6 メモリ管理 0.7 ファイルシステム 0.8 ネットワーク 0.9 プロセス間通信 0.10 Linuxカーネルの起動 0.11 Linuxカーネルの動作例 Part 1 カーネルプリミティブ第1章 プロセススケジューリング 1.1 マルチタスク 1.2 プロセスとは? 1.3 プロセス切り替え 1.4 プロセスディスパッチャの実装 1.5 プロセススケジューラ 1.6 プロセススケジューラの実装 1.7 事象の待ち合わせ 1.8 最

    Linux Kernel Document Wiki @ SF.jp
  • linuxやるブログ yum localinstall

    yum localinstall ローカルにあるのrpmファイルをyumでインストールする方法。 依存性のファイルをレポジトリから探してきてくれるのが超便利です。 例) カレントディレクトリにある ant-1.6.5-2jpp.2.x86_64.rpm をyumでインストールする。 # yum localinstall ant-1.6.5-2jpp.2.x86_64.rpm ============================================================================================================================= Package Arch Version Repository Size ================================================

  • コマンドによる「負荷」の原因切り分け

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    コマンドによる「負荷」の原因切り分け
  • Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログ

    社内で論文輪読会みたいなことやってて、そこで紹介した論文の内容についてです。 最近、Graphite に保存しているデータのバックアップ(データ同期)に rsync 使ってて、かなり遅いので困ってた。 LISA っていう 大規模システム、sysadmin 系のカンファレンスがあって、ここから論文探してたら、ちょうど巨大データの高速バックアップの実装の話があったので読んでみた。 論文概要 dsync: Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data - https://www.usenix.org/conference/lisa13/technical-sessions/presentation/knauth - Thomas Knauth and Christof Fetzer, Technische U

    Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログ
  • 1