タグ

bottleneckに関するmoronbeeのブックマーク (4)

  • 「AIを全員に配った組織」の生産性が落ちるとき - 🐴 (馬)

    (注: 8/10 に説明の構成を大幅に変えました。) 2005年に完成したソウル市の清渓川復元事業では、都心を貫く高架道路が撤去され、その下に埋もれていた川が復元されました。都心の大動脈を消すと、交通は麻痺するように思えます。 実際、工事直後には一時的な速度低下もあったようです。しかしその後は地下鉄利用が増え、道路移動が減り、懸念された大渋滞がそのまま固定化することはありませんでした。(ただし、同じ時期にはバス路線の再編や中央バス専用レーンの整備など、公共交通改革も行われています。道路撤去だけの効果と考えるべきではありません。) 交通の領域では、道路を増やしても、増えた容量に応じて交通量も増えてしまい、渋滞がなかなか解消しないこと(誘発需要)が知られています。逆に、道路を減らしても、恐れられたほどの渋滞は起きず、交通の一部が消えてしまうこと(交通蒸発)も繰り返し観察されてきました。清渓川で

    「AIを全員に配った組織」の生産性が落ちるとき - 🐴 (馬)
    moronbee
    moronbee 2026/08/09
    TOC(AI対応版)で考えるべきポイント。新しい問題を既存工学と対比して解決を試みるのいいね
  • 開発が速く安くなった後の話 AI時代のソフトウェアエンジニアリング組織論 #devsumi

    2026/7/16に、Developers Summit 2026 Summerで発表した黒田の資料になります。

    開発が速く安くなった後の話 AI時代のソフトウェアエンジニアリング組織論 #devsumi
    moronbee
    moronbee 2026/07/20
    越境説明に効く抽象化が上手い。開発・運用コストやセキュリティ含めた要求定義・要件定義をスマートにできる組織は確実に強くなる。反面、開発に丸投げしてたり噛み合ってない組織は益々苦しくなる。
  • 第2回 最大の課題「I/Oボトルネック」の原因と分析法 | gihyo.jp

    I/Oの「レスポンス」と「スループット」とは? 連載第1回でご紹介したように、大規模データ処理を行うデータベースで一番大きな課題となるのは、ディスクI/O(以降、単にI/Oと表記します)のボトルネックです。数百GBやTBクラスの巨大データウェアハウスの場合、SQLが実行される時間のほとんどがI/Oを待つ時間となっているケースが多々あります。 ここでは、I/Oボトルネックが発生するおもな原因を、「⁠レスポンス」と「スループット」という概念から見ていきましょう。それぞれ、広義では以下の定義となります。 I/Oレスポンス=I/O要求処理にかかる応答時間 I/Oスループット=単位時間当たりのI/O処理量 Oracle Databaseに当てはめると、以下のように定義できます。 I/Oレスポンス=1データブロックの読み出しや書き込みにかかる時間 I/Oスループット=単位時間あたりの読み出しや書き込み

    第2回 最大の課題「I/Oボトルネック」の原因と分析法 | gihyo.jp
  • システムの負荷の原因を切り分ける方法 - Qiita

    サーバのボトルネックを探る サーバが重い時、主に以下の4つがボトルネックとなる。 CPU使用率 メモリ使用量 ディスクI/O TCPコネクション数 この記事では、これらのうちどれがボトルネックとなっているかを突き止める方法について書く。 ロードアベレージを見る まずはロードアベレージを見ることで、おおまかに問題を切り分ける。 ロードアベレージの確認方法はload averageを見てシステムの負荷を確認するに書いた。 ロードアベレージが高い場合 現在のホストの**「1. CPU使用率」**, 「2. メモリ使用率」, **「3. ディスクI/O」**を疑う。 ロードアベレージが1以下であれば軽く、1〜3くらいだとやや重く、それ以上だとこれらがボトルネックの可能性が高い。 ロードアベレージが低い場合 **「4. TCPコネクション数」**か、リモートホストがボトルネックになっていないか疑う。

    システムの負荷の原因を切り分ける方法 - Qiita
  • 1