[TCP ZeroWindow] が示す状況[TCP ZeroWindow] が送信される、というのは、TCP においてデータ受信側が「もう処理しきれないから一度送るのを待って!」と送信側に伝えている状況です。 具体的には、相手に Ack と共に、TCP の "Windowフィールド" を 0 にセットしたパケットが観測されたときに表示されます。 [TCP Window Update] が示す状況一方、[TCP Window Update] の送信は、「処理できるバッファが出来たから送信を再開して下さいね!」と送信側に伝えている状況です。 具体的には、ZeroWindow と同じ ACK 番号で、TCP の "Windowフィールド" に自身の受信バッファ分の数値をセットしたパケットが観測されたときに表示されます。 なお、通常の TCP のやり取りの中でも Window の Update
少し前の雑誌で恐縮ですが、今でもネットで手に入るWeb+DB PressのVol.120の特集「Webページが表示されるまで HTMLを運ぶプロトコルとシステムコールの裏側」がとてもいいので、紹介です。 WEB+DB PRESS Vol.120 https://www.amazon.co.jp/dp/B08Q764JKR/ref=cm_sw_r_tw_dp_0F5JA6ASV4K8YZTB3EJS インフラ分野でエキスパートになりたい人は、システムコールを学ぶべきと私は思うのですが、そのきっかけとして良い記事だと思います。 なお、サンプルがC言語で書かれているので、そこは「ふーん」と読み飛ばしてもいいと思います。 システムコールそのものの話は記事を読んでもらうとして、この記事で書かれている内容が実際の現場でどう使えるのか、私の経験を基に紹介してみたいと思います。仕組みを学ぶと例えばこんなこ
YAMAHAのRTX1200でVPNを組みました。 構成としては以下のようなスター型のネットワークで、外部へのインターネットもセンター側を経由して行くようにしています。 さて、拠点側から一部のWEBサイトが見えないという問合せがありました。 例えばMicrosoftのサイト(htt://www.microsoft.com/)とか、借りている一部のレンタルサーバ上のWEBとかです。 IEで見ると、ずっと接続に行ってるような感じですが、何も表示されず最終的にタイムアウトしてしまっているようです。 Googleとかは普通に表示されまし、センター側の端末も何も問題なく表示されます。 ということで、拠点側のPCで WireShark を使ってパケットをキャプチャして見ました。 閲覧できないレンタルサーバ上(IP:xxx.xxx.xx.xxx)に、数キロバイトのHTMLを置きそれにアクセスした時の状態
dbus-daemonのCPU使用率が高いので調査依頼を受けました。 何はともあれトレースして見ます。 straceの出番です。 $ sudo strace -o dbus.log -ttf -s 512 -p `pidof dbus-daemon` 712 10:58:37.914418 fcntl(-1, F_GETFD) = -1 EBADF (Bad file descriptor) 712 10:58:37.914546 epoll_wait(4, [{EPOLLIN, {u32=3, u64=5298502605327040515}}], 64, -1) = 1 712 10:58:37.914623 accept4(3, 0x7ffd7c185110, 0x7ffd7c18510c, SOCK_CLOEXEC) = -1 EMFILE (Too many open files
ルーターを語る上で避けて通れないのが MTU / MSS ですね。自分も L2TPv3 によるレイヤー2 VPN を設定したのを機に、きちっと計算してみました。 MTU / MSS とは MTU は通信インターフェースが通せる最大データサイズ、 MSS は TCP/IP の通信の際のデータ(ペイロード)の最大サイズです。例えば大抵の LAN のインターフェースである Ethernet の場合 MTU は 1500 バイトです。その Ethernet で TCP/IP のパケットを流す場合、 MSS は大抵の場合 MTU – IP ヘッダ – TCP ヘッダ = 1500 – 20 – 20 = 1460 となります。パケットの大きさが MTU の大きさを超えると不必要にパケットが分割され、通信が遅くなります。そのようなオーバーヘッドを避けるには、ルーターで適切に MTU / MSS を設定
MySQLでロックが発生しているスレッドを特定(+強制終了)する方法です。 よく忘れるのでまとめてみました。 間違っているところはマサカリお待ちしています。 ロック状態の確認方法 1.件数だけ mysql> SELECT trx_rows_locked FROM information_schema.INNODB_TRX; +-----------------+ | trx_rows_locked | +-----------------+ | 1 | +-----------------+ 1 row in set (0.00 sec) mysql> SHOW ENGINE INNODB STATUS\G ... ------------ TRANSACTIONS ------------ Trx id counter 709 Purge done for trx's n:o < 708
The Windows SDK (10.0.28000) for Windows 11 contains the latest platform headers, libraries, WinRT metadata, and build tools required to develop Windows applications. It supports both UWP and Win32 development and can target Windows 11, version 26H1, in addition to previous Windows releases. By using this SDK, developers gain access to the full set of Windows APIs and capabilities needed to build
WDKなみなさま、お元気ですか。さなえすです。 前回の原稿を書いていて思い出したのですが、私が Windows Kernel の世界に入門したばかりの頃のことです。メモリ ダンプ ファイルというものに初めて触れた時、先輩から『…じゃあ、とりあえずビックリアナライズハイフンブイしてみて。』と言われた時は、状況が飲み込めず『???』という感じだった事を覚えています。私の様子に気づいた優しい先輩がその後にきちんとフォローしてくれたおかげで、『(カーネルデバッガーで、メモリダンプ ファイルを開いて)”!analyze -v” コマンドを打ってみて』ということだと理解できたのですが。ちなみに、経験則から言うと、“!” は、日本語では “びっくり”、英語では “Bang” (バング)と読むみたいですね。 さて、前回に引き続き、メモリダンプ ファイルのお話です。 「メモリダンプに !analyze -v
If I add preprocessors: {'**/*_test.js': ['webpack']} and I have 100s of tests, that produces 100s of large bundles - that's slow, reruns tests all the time since karma keeps detecting changes and rerunning all ests as each test bundle is produced by webpack and this sends many megabytes to the test browser to evaluate. Instead, if I add preprocessors: {"test_index.js": ['webpack']} and require al
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く