cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
Squidがアクセス集中時に遅くなったときに行った対策 - 技術メモなど
始業時や昼休みなど、アクセスが集中する時間帯になるとLinuxのSquidプロキシサーバのレスポンスが悪くなって、「Webアクセスが遅い！！」とあちこちから苦情を言われてしまっていたのですが、次のような対策を行ったところ、無事解決できたっぽいのでメモることにします。 現状の確認 CPUやメモリの使用率を確認 まずはお決まりのtopコマンドをアクセス集中時に実行（topコマンド自体が高負荷時にはサーバに更に追い打ちをかけそうですが、原因の切り分けのためにはやむを得ないと思います）。やはりsquidプロセスが一番CPUもメモリも喰っていましたが、load averageは低く、CPUやメモリに負荷がかかっているようには見えない状況でした。 ネットワークの状況を確認 次に同じくアクセス集中時にnetstatコマンドを実行。すると状態がESTABLISHEDのコネクションよりもTIME_WAITや
【Linux】ファイルディスクリプタとは何か – FiS Project
HTTPサーバが複数のクライアントを識別できる背景にはファイルディスクリプタの存在があります。ファイルディスクリプタが存在しないと, サーバは誰にレスポンスを返して良いかわからなくなってしまいます。 今回はファイルディスクリプタの基礎について。 Stream ファイルディスクリプタを理解するには Stream[1] が何かを知る必要があります。 下図のようにプロセスからファイルにアクセスするときに, 通り道となるのが Stream です。バイト列が流れることから byte-stream とも呼ばれます。 プロセスからプロセスに繋ぐときには pipe[2]を使いますが、この時にバイト列を結びつけるのも Stream です。 Stream を制御するのはカーネルの役割で, open(2), read(2), write(2) などのシステームコールを通じて Stream を出してもらいます。
ファイルディスクリプタについて理解する - Qiita
ファイルディスクリプタについて分かっているような分かっていないような感じだったのRubyでコードを書きつつ、理解したときのメモ 参考 ファイルディスクリプタ数の上限変更とlimits.confの罠 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Shinpeim/process-book そもそもファイルディスクリプタとは何か 以下より引用 IT用語辞典 ファイルディスクリプタとは、プログラムがアクセスするファイルや標準入出力などをOSが識別するために用いる識別子。0から順番に整数の値が割り当てられる。OSによってはファイルディスクリプタにバッファ管理機能なども含めた「ファイルハンドル」と呼ばれる管理体系が存在する。 ファイルディスクリプタには、識別子とともにファイル名、ファイルサイズ、プログラムが操作中のファイル内の位置、ファイル作成、更新日時などの情報が含まれており、OSは
なぜプレゼンで失敗するのか - 詩と創作・思索のひろば
自分も大方の人間と同じように人前で喋るのは苦手で、可能であれば避けたいと思っているけれど、一方でこの業界で生きのこる方法のひとつとして避けられないものでもあると思っている（ので苦しい）。若かりしころ手痛い失敗をしたこともあって、かなり苦手意識を持ちつづけていたが、最近はわりかし上手く付き合えるようになってきたかなとふり返って思う。 今もうまいプレゼンテーションをする方法は知らないし、それを僕から知りたいという人はいないとおもうが、プレゼンでしくじる方法なら経験から知っている。準備をしないこと。自分の経験からはそうだし、まずいプレゼンを見ていてもそうなんだろうな、と思うことはやっぱり多い。 このエントリはプレゼンがいやでいやで仕方がなかった自分のための分析であり、プレゼンのマイナスレベルをゼロまで引き上げようとする努力です。ソフトウェアエンジニアの技術者間交流のためのプレゼンというのが前提。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
