全て 1.このサイトについて 2.作品DB開発/運用 3.ホームページ制作技術 4.Perl 5.C言語 / C++ 6.検索エンジン&SEO 7.サッカー 8.自分のこと 9.Linux 10.旅行 11.思ったこと 12.パソコン 13.Berkeley DB 14.その他技術系 15.企画 16.スマートフォン 17.鑑賞 18.皆声.jpニュース 19.インターネット業界 20.運用マニュアル(自分用) 21.技術系以外実用書 22.料理 23.ALEXA 24.アニメ 25.会計 26.漫画 27.設計書 28.色々サイト作成 29.サーバー 30.自分専用 31.生活 32.OP/ED/PV 33.ゲーム 34.DB整備 35.新規開始作品紹介 36.英語圏の話題 37.大道芸 38.映画 39.PHP 40.ダイエット 41.Mac 42.JavaScript 43.MySQ
「特定CPUコアでのボトルネック」と「リソースの奪い合い」が2大ボトルネック 第2回、第3回ではディスクI/Oボトルネックについて説明しました。レスポンスとスループットの関係を正しく理解し、I/Oスループットを最大化するようチューニングすれば、ほとんどの大規模処理は速くなります。ユーザもハッピー、皆さんもハッピー、さて家に帰りましょう。 ……しかし、次はだれかからこう聞かれることでしょう。 「CPUの使用率が異様に低いままなんだけど……?」 「CPUの使用率がずっと100%で張り付いているんだけど……?」 どっちやねん!と思うでしょうが、どちらも大規模データを処理するときに特に起こりえる問題です。 ボトルネックは、1つが解消すると、新たなポイントが明らかになるものです。そして多くのケースにおいて、ディスクI/Oボトルネックが解消した場合、次に詰まるのはCPUなのです。 CPUボトルネックは
今までは「sar -P ALL 1」とかでリアルタイムに表示させていたけど、topコマンドでも表示できるのでメモ top - 11:01:33 up 90 days, 23:09, 2 users, load average: 0.16, 0.06, 0.10 Tasks: 219 total, 1 running, 218 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 0.3 us, 0.0 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu2 : 0.7 us, 0.3 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 s
マルチコアがどれくらい有効なのかは、ユーザーの使用の仕方で大きく変わってきます。 具体的な「使用中に他のアプリや別のプログラムを実行する」の頻度次第ですね。 しかも、単に複数のシングルスレッドアプリを立ち上げるだけでは、マルチコアの意味はありません。 まず、通常の利用方法である、同時に1アプリしか使っていない状況でも、 デュアルコアの意味はあります。「OS」と「使用しているアプリケーション」の2スレッド。でも、この場合は3コア以上あっても意味無し。 あるアプリの使用中に他のアプリを立ち上げても、その両方を同時に使うのでなく、切り替えて使う場合は、使ってない方のアプリはCPU時間を消費しません。 ここで「常時稼働してCPU時間を消費する」ようなアプリを裏で稼働させるような作業をして、初めて3コア目が役に立ちます。 たとえば、「通常の作業をしながら、裏でウィルス対策ソフトによるスキャンをする」
この記事は feedforce Advent Calendar 2016 - Adventar の2日目の記事です。 1日目は 源義経のシンプルな考え方が好き - Marketing book でした。良い話だ。(ちなみに大河ドラマが平清盛だった年は、我が家では後白河院の評価が高かったです。懐かしい。) RubyCriticのご紹介 rubyエンジニアなのでrubyのことを書きます。 RubyCriticはrubyコードを静的解析するツールです。rubygemで提供されています。 単純な使い方としては、$ gem install rubycritic するなりbundler使うなりしてインストールし、 $ rubycritic . を実行します。$ rubycritic ./app ./lib のように、指定のディレクトリだけを対象にして実行することもできます。 実行すると./tmp/ru
ところで私は、かつて「手を動かさない人」でした。 仕事にせよ、勉強にせよ、創作にせよ、音楽にせよ、どんなことでも「ごちゃごちゃ考えているより、まずやってみて場数をこなした方がスキルは育つ」というのは、大体の場合で当てはまる普遍的なセオリーであると思います。 ゲーム開発、アプリ開発なんかでも、実績を残している人はみんな「いいからまずやってみろ」って言いますよね。 手を動かすこと、超大事です。手を動かすことによって、課題が生まれ、自信が生まれ、ノウハウが蓄積されていく。頭で考えているだけでは何も始まりません。考えたものは、出力しなくてはいけません。 ところが、世の中には「手を動かさない人」がいます。取り敢えずやってみろ、というアドバイスを受けつつも、なかなか「取り敢えずやってみる」という実施タームに移れない、もしくは移らない人ですね。先日、Books&Appsさん内でもそれについての記事が掲載
はじめに 2016/12/01 に行われた Rollout.io MeetUp に参加してきたので、そこで聞いた話をベースに Rollout をご紹介いたします。 Rollout とは Rollout は iOS 向けのアプリケーションに審査なしでパッチを当てるためのサービスです。 いろんな方が経験していると思うのですが、アプリをリリースしたものの、重大なバグを見つけてしまった場合、再度アプリを審査に出して反映を待つ必要があります。しかもストアに反映されたとしても、ユーザーはアプリを再度落とし直さないとその修正は反映されません。 Rollout を用いると、Web のインターフェースから JavaScript でパッチを作成することで、審査なしですぐにバグの修正や機能の解放を行えます。これによって、通常は再度審査をはさむ必要があるバグ修正であっても、アプリのユーザーはアプリを落とし直す必要
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く