タグ

linuxとserverに関するaiueo010101のブックマーク (6)

  • tc: Linux HTTP Outgoing Traffic Shaping (Port 80 Traffic Shaping) - nixCraft

    When traffic is shaped, its rate of transmission is under control, in other words you apply some sort of bandwidth allocation for each port or or so called Linux services. Shaping occurs on egress. You can only apply traffic shaping to outgoing or forwarding traffic i.e. you do not have any control for incoming traffic to server. However, tc can do policing controls for arriving traffic. Policing

  • daemontools の代替として Supervisor がよさげ

    node.js なサーバデーモンの管理をしようと思い、何を使おうか検討していたのですが、この手のデファクトスタンダードである daemontools は、特定のディレクトリ構造に従わないといけなかったり、run スクリプトや log/run スクリプトを置いたりしきゃいけなかったりで、余計な作業が多くてお手軽じゃない、ってことで runit を見てみたんですが、ぱっと見 daemontools との違いがよくわからなくて、daemontools とそれほど煩雑さは変わらないように見えたので、もっとお手軽なものがないかと探していたところ見つけたのが Supervisor 。(といっても自分が知らなかっただけで以前からあるみたいですが。) Python 製で easy_install 一発でインストールできる。 $ sudo easy_install supervisor デフォルトの設定フ

  • リモートのマシンで、iptablesでなんかいじる前に保険をかけておく - (ひ)メモ

    #!/bin/sh # 保険をかける # echo '/root/clear-iptab' | at now + 3min # とか # echo '/root/clear-iptab' | at 13:00 # で。 # # そしたら iptables でなんかいじって、 # iptables ... (as you like) # 成功したら at の job を削除しておわり。 # atq # atrm N # 失敗したら正座して祈る。 iptables -F iptables -X iptables -Z iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT 追記: 2010-01-09 http://ya.maya.st/d/201001a.html#s20100107_1 で言

    リモートのマシンで、iptablesでなんかいじる前に保険をかけておく - (ひ)メモ
  • sshでリモートサーバーをマウント、便利にsshfs - Unix的なアレ

    開発の作業をしているときは、複数のホストのサーバーを行き来していろいろとオペレーションをするようなことがあると思います。 そんなときに1つのサーバーから作業できるよう、ssh経由でリモートのサーバーをマウントし、Localのファイルシステムのように見せることができるsshfsを紹介したいと思います。 sshfsのインストール Debian/Ubuntuならaptで簡単インストールできます。なお、fuseグループに入っている必要があるので、その設定まで実施します。なお、ユーザー名はwadapで実施します。 $ sudo apt-get install sshfs $ sudo adduser fuse wadap $ newgrp fuse以上、簡単ですね。 早速リモートホストをマウント リモートホストをマウントするのは簡単です。マウントポイントをつくって、sshfsコマンドを実行するだけ。

    sshでリモートサーバーをマウント、便利にsshfs - Unix的なアレ
  • 常駐型サーバープログラムのデバッグ手法

    BOOK: WEB+DB Press TITLE: 常駐型サーバーのデバッグ手法(ドラフト版) AUTHOR: (株)プリファードインフラストラクチャー 太田一樹 *注: この文章はWEB+DB PRESS Vol.48に掲載された記事のドラフト版です はじめに 今回はデバッグ関連特集ということで、常駐型サーバープログラムを作成する際のハマりどころやそれに対する解析方法・解析ツール・対策を、実際の経験を交えながら紹介したいと思います。 筆者は(株)プリファードインフラストラクチャーでインメモリ分散検索エンジン「Sedue (セデュー)」を開発しています。モバイル向け検索エンジン「エフルート」や、2008/11/6にリニューアルされました「はてなブックマーク2」などの検索バックエンドとして使われております。 この検索エンジンはいくつかの常駐型サーバープログラムから構成されており

  • naoyaのはてなダイアリー - tmpfs は本当に容量が動的なのか

    Linux には tmpfs という便利なファイルシステムがあります。 $ mount -t tmpfs -o size=64m tmpfs /dev/shm $ mount -t tmpfs -o size=64m /dev/shm /var/tmpとすると、/var/tmp がディスク上ではなくメモリ上に作られたファイルシステムとして mount されます。なので、/var/tmp は I/O 時にディスクI/Oが一切発生しない高速なディスクとして使えると。いわゆる RAM ディスク。(もちろんサーバーの電源を落とすと保存したファイルは消えます。) この tmpfs はなかなかに便利で、キャッシュとかそういうものでディスクにおいてたものここ置くと、ディスク I/O がカットできて超高速になります。はてなでは MySQL のスレーブの MyISAM のファイルを tmpfs において、オ

    naoyaのはてなダイアリー - tmpfs は本当に容量が動的なのか
  • 1