VyOS Wiki
Welcome to the VyOS project, a Linux-based network operating system. VyOS is a Linux-based network operating system that provides software-based network routing, firewall, and VPN functionality. How it's different from other router distros? Unified command line interface in the style of hardware routers. Scriptable CLI Stateful configuration system: prepare changes and commit at once or discard, v
訳：非推奨になったLinuxネットワークコマンドの代替コマンド - aws memo
これはちゃんとチェックしておかないとなぁ。 Deprecated Linux networking commands and their replacements « Doug Vitale Tech Blog ==== この記事で詳しく説明する非推奨のLinuxネットワークコマンドは：arp, ifconfig, iptunnel, iwconfig, nameif, netstat, route である。iwconfig以外の コマンドは、net-toolsパッケージという、数年間メンテナンスされていないパッケージに含まれている。これらのユーティリティによって提供される機能は、新しいipコマンドを主に使うiproute2 スイートで再提供され、改善され続けている。iproute2ソフトウェアのコードとドキュメントは、Kernel.orgとLinux Foundationで見ることができ
ulimitが効かない不安を無くす設定 | 外道父の匠
limits.conf に書いても ulimit に効いていない、というのはよくある話です。 ulimit が少なくて困ったことはあっても、多くし過ぎて困ったことはほとんどないでしょうから、ドーンと全条件下でulimit設定を効かせる方法を紹介します。 ulimitが効かない問題 だいたいこんな内容だと思います。 SSHログインだと効かない su すると効かない OS起動時に自動起動したデーモンに効かない 普通はデーモンに効けばよいので、本当に困ったら起動スクリプトに直接書いたりしますが、方法としてはイマイチなのでちょっと工夫をします。 その前に・・・ PAMについて PAMというユーザー認証システムについてはググっていただくとして、よく出てくる /etc/security/limits.conf という設定ファイルは、PAMを通る条件下でしか有効になりません。 ではPAMを通るとはどうい
Dockerコンテナのファイルディスクリプタ設定 - Qiita
やりたいこと fluentdを使うにはファイルディスクリプタ（FD）の数を増やしておく必要がある。これをdockerコンテナに対して設定したい。しかしこれは残念ながらホスト側やdocker側の設定が必要になりDockerfileには書けない。ここを参考に設定してみた。fluentdに限った設定ではないので、いろいろな用途に使えるはず。 とりあえずこうしてる どなたかもっとよい手順があれば教えてくだされ。 ホスト：Debian 7 on Google Compute Engine ゲスト：Ubuntu 12.04 Docker v0.8.1 ホスト側のFDを増やす /etc/security/limits.confでFDを増やしても自動起動スクリプトには効いてくれないので困っていた。外道父さんのエントリを参考に、/etc/initscriptを以下のように書いて追加したらうまく動いた。外道父
SPDYとLinuxの間でGoogleマップがハマった落とし穴 - ぼちぼち日記
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど１年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
RSS対応NICなのに割り込み処理が複数コアに分散しない…のはirqbalanceが動いてなかったから - 酒日記 はてな支店
タイトルがすべてでございます。 NICの割り込み処理が1コアに集中してしまい、ボトルネックになって性能が出ない場合があるという話は最近広く知られていると思います。 NICのハードウェアレベルで割り込みを分散してくれる RSS(Receive Side Scaling) という仕組みがあり、それを利用すれば特になにもしなくても複数コアに分散されるはず、と思っていたのですが、どうも特定のマシンでそうならない。 # cat /proc/interrupts CPU0 CPU1 CPU2 (省略) CPU11 64: 1256214 0 0 ... 0 IR-PCI-MSI-edge eth1-0 65: 225711 0 0 0 IR-PCI-MSI-edge eth1-1 66: 402906 0 0 0 IR-PCI-MSI-edge eth1-2 67: 723539 0 0 0 IR-P
Linux サーバでの「Too many open files」対策について - akishin999の日記
Linux サーバでの「Too many open files」エラー対策について調べたのでまとめてみました。 確認した OS は CentOS 5.9 と CentOS 6.3 です。 「Too many open files」は Linux でプロセスが開けるファイルディスクリプタの上限に達してしまうと発生するエラーです。 「ファイルディスクリプタ」という名前ですが、 Linux ではソケットもファイルディスクリプタなので、ファイルを開いた場合だけでなく、ソケットを使って通信を行う場合にもファイルディスクリプタが使用されます。 そのため、Apache や Tomcat などで高負荷なサイトを運用している場合などには、比較的遭遇する確率の高いエラーではないでしょうか。 このエラーを回避するため、プロセスがオープンできるファイルディスクリプタの上限を変更します。 まずは以下のコマンドを実行
超高速なパケットI/Oフレームワーク netmap について - ゆううきブログ
GPUを用いたSSLリバースプロキシの実装について - ゆううきブログ 100Gbpsソフトウェアルータの実現可能性に関する論文 - ゆううきブログ の続きで，最近論文読んだやつのプロジェクトの紹介です． 概要 今の汎用OSは高速なパケットI/Oを考慮してない． 20年前のAPIをそのまま使っている． ネットワークがどんどん高速になっているので，NICとかOSカーネルのパケット処理がボトルネックになってる． (http://news.mynavi.jp/news/2013/04/04/094/index.html) こういうの解決するために既存手法がいろいろある． Linux packet mmap - IwzWiki Linux Kernel Documentation :: networking : packet_mmap.txt DNA (Direct NIC Access) Pac
[Linux] 同一ネットワークの複数IPアドレスを割り当てる際の注意点 | EastCamp
一台のLinuxマシンに同一ネットワークの複数IPアドレスを割り当てる際には注意が必要。[Linux] 同一ネットワークの複数IPアドレスを割り当てる際の注意点 一台のLinuxマシンに同一ネットワークの複数IPアドレスを割り当てる際には注意が必要。 ARP応答に関する問題 LinuxカーネルのARPに関する仕様が以下のようになっているため。 LinuxではIPスタックの処理をカーネルが担当しているが、ARP解決要求に対する返答は以下のロジックとなっている。 クライアントからARP解決要求のブロードキャストを受信 カーネルは自身の持つIPアドレスとマッチするかを検査 ARP解決要求を受信したインタフェースのMACアドレスをARP応答として返す。 ２において、このときIPアドレスがどのインタフェースにバインドされているかは特に関係が無い。 これにより、同一ネットワーク（同一ブロードキャストド
TCP Fast Open を試してみる - nigakyのブログ
Linux カーネル 3.6 では TCP Fast Open (TFO) という機能がマージされたそうです。詳しくは以下の URL に記載がありますが、一度接続したクライアントは TCP の 3way-handshake を簡略化してコネクションをオープンできる（SYN にデータを載せられる）という機能のようです。 TCP Fast Open: expediting web services [LWN.net] 面白そうな機能なので実際に使ってみて、使い方をまとめてみました。 準備 カーネル kernel 3.6 ではまだクライアント側の機能しかマージされていないので、さらに新しいカーネルを使います（3.7 でサーバ側の機能もマージされるようです）。今回は git で取ってきた最新 (12250d843e8489ee00b5b7726da855e51694e792) をビルドして使いまし
Linux kernel 3.9 の新機能 SO_REUSEPORT を試してみる - nigakyのブログ
Linux kernel 3.9 のマージウィンドウでは SO_REUSEPORT というソケットオプションがマージされました。 Merge branch 'soreuseport' · c617f39 · torvalds/linux · GitHub これは同一ポートに複数のリスナー（listen ソケット）が bind できるようになるというもので、Webサーバなど単一のポートに多くのコネクションが来るようなワークロードで、複数プロセスでうまく負荷分散ができるようになるそうです。 （これまでだと一人がaccept()してそれぞれの worker に渡すというようなモデルがありましたが、これでは accept() する部分がボトルネックになってしまいがちでした。） BSDでは元々 SO_REUSEPORT オプションはあったようですが、マルチキャスト通信で使うもののようです。Linux
Linuxサーバ上のHTTPプロキシサーバでシステム負荷が高くないにもかかわらず処理が遅い場合：TechLabo：So-netブログ
仕事で、Linuxサーバ上でHTTPプロキシサーバとして動作するとあるURLフィルタリングソフトを使っているユーザから、「お昼頃からプロキシサーバ経由でのアクセスが非常に遅い、ちなみにCPU使用率とメモリ使用率、ディスクI/Oは正常時と変わりないのになぜ？」という問い合わせがあり対処したときのメモ。 システムリソースの負荷が高くなく、処理遅延が発生している場合の疑う点としては、 ファイルディスクリプタが不足している アプリケーション（プロキシサーバ）の最大同時接続数以上のアクセスを受け付けている カーネルチューニング不足 の3つが考えられる。 1．のファイルディスクリプタ不足はプロキシサーバアプリケーションが1セッション1スレッドで動作するようなもの（メジャーなものではsquidなど）が発生しやすい。 ログファイルに”too many open files”というメッセージが記録されるので
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
さくらのVPSでファイアーウォールが何も設定されていないのに驚愕したが ufw で解決 - babie, you're my home
さくらのVPS ってデフォルトではファイアーウォールの設定何もされてないという記事をみて驚愕した。と、よく考えたら Ubuntu 10.04 LTS を再インストールしたから、どっちにしても初期状態だな。 とりあえず確かめた。 $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination オウフ、デフォルトは空なのか…… iptables の設定めんどくせぇなーどうしようかなー、と思っていたら、どうも Ubuntu では ufw という
nc(netcat)で超簡易ファイル転送 - うまいぼうぶろぐ
ncを使えばなんでもできる！ なんでも出来すぎて困っちゃうので、これ知っとけば便利ですよ的なおすすめ使い方を１つ書く。思いつきで。 ファイル転送 このファイルを ○○サーバにupしたいけど、ここからだとFTP/SSHの許可設定が入ってなくて接続できないなー、とかいうときに。 ncはdebian/redhatのdistribution packageで オプションが違った気がするので少し注意。この例はredhat系。 送信側 適当に空いてるport番号でlistenする。ここでは10000番を使用。標準入力で送信したいファイルを指定。 $ nc -l 10000 < filename 受信側 送信側ホストの10000番に接続。標準出力をリダイレクトして、ファイル保存。 $ nc 送信側ホストのIP 10000 > filename 確認 実行してみればわかるけど、ncはファイル送受信専用なs
LAN内で使用中のIPアドレス(pingで応答があるノード)を簡易に調査するワンライナー(Linux編) - 元RX-7乗りの適当な日々
昨日、書いたメモエントリ。 LAN内で使用中のIPアドレス(pingで応答があるノード)を簡易に調査するワンライナー(Windows編) "Windows編"と書いたからには、"Linux編"も書いておこうかと思いまして、bash版を。(どこでも実行できる様、ポータビリティ重視ｗ) $ for a in `seq 1 254`; do ping -c 1 -w 1 192.168.1.$a > /dev/null && arp -a 192.168.1.$a | grep ether; doneちょっと長いですが、こんな感じかしら。(ブロードキャストパケットを拒否するノードがいたので・・・。) ファイル等ログ出力したい場合は、リダイレクトを付けて実行してください。 詳解 シェルスクリプト 作者:Arnold Robbins,Nelson H. F. Beebe出版社/メーカー: オライリー
DSAS開発者の部屋:いかにして冗長構成を作るか 〜DSASの場合〜
DSASはいかにして可用性を高めているか、ちょっと紹介したいと思います。 今回は概略ということでざざざっと説明します。個別の構成についてはまた回を改めて紹介したいと思います。 │ │ ┌┴┐ ┌┴┐ │ │ │ │ISPの上位ルータ └┬┘ └┬┘ │ │ 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 責任分解点 │ │ ┌┴┐ ┌┴┐ │ ├─[ lb(active) ]─┤ │ │ ├─[ lb(backup) ]─┤ │ │ │ │ │ │L2├─[ Web ]─┤L2│ │SW├─[ Web ]─┤SW│ │ ├─[ Web ]─┤ │ │ │ │ │ │ ├─[ SMTP ]─┤ │ │ ├─[ SMTP ]─┤ │ │ │ │ │ │ ├─[ D B ]─┤ │ │ ├─[ D B ]─┤ │ │ │ │ │ │ ├─[ NFS ]─┤ │ │ ├─[ NFS ]─┤ │ │ │ │ │
DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1)
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - jpetazzo/pipework: Software-Defined Networking tools for LXC (LinuX Containers)
マルチコアとネットワークスタックの高速化技法
