Linuxカーネルパラメータのチューニング＆設計 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Linuxカーネルパラメータのチューニング＆設計 0.目的 【カーネルパラメータのチューニング】を修得する目的は、サーバの特性を理解し、それぞれに合ったカーネルパラメータのチューニングすることでリソースの有効活用をできるようになることを目的とし、私個人の経験を元にした見解を以下の記事に掲載します。 1.最初に サーバには、それぞれ必要なリソース特性があり、それに合わせたカーネルパラメータのチューニングが必要となります。 世の中の流れはオンプレよりクラウドに移行してはいるので、カーネルパラメータのチューニングよりスケールアップなりスケール
Z80+C言語で16ビット機級の本格的なゲームが創れるゲーム機（VGS-Zero）を作ってみた - Qiita
なお、キャラクタパターンテーブル（8KB）は VRAM に展開しなくても ROM のバンク番号を指定して VROM として扱う機能（DPM; Direct Pattern Mapping）もあり、その機能を使えばキャラクタパターンテーブルの 8KB を RAM として代用することもできます。 ROM の特定バンクをキャラクタパターンにロードする DMA 機能があるので、例えば RPG や STG のマップなど、ROM バンクから色々なデータを読み込むためのロード・エリアとして活用することを想定しています。（キャラクタパターンテーブル本来の用途よりも代用の用途の方がメインになる想定です） VRAM サイズを 16KB にしたのは Z80 でのプログラミングをしやすくするため（Z80 ファースト） です。 VRAM と RAM が各 16KB になっているからこそ、I/Oを一切使わずに RAM
原因不明だったRDS負荷のスパイクを改善できた話 - Qiita
概要 当時数ヶ月間誰も原因がわからなかった一時的にRDSの負荷（CPU使用率）がスパイクする現象の原因を調査できる環境を整えて、原因分析〜改善まで実施したときの話です。 1つ1つの取り組み自体は大きなことはやっていませんが、一連の動きで得られたものも多かったのでアウトプットしようと思い記事にまとめました。 取り組んだ課題 原因を特定するためのツールがない そもそも何が原因でRDSのCPU負荷が高まっているのかを調べるための情報がCPU使用率以外に全くない状況でした。 そこでRDSの負荷原因を探る方法を調べると、Performance InsightsやCloudWatch Logsへのスロークエリログ出力を使う記事をいくつか見つけたのでこの2つについて調べることにしました。 Performance Insights データベース負荷をSQLなどの単位で時系列で可視化したり、トップSQLやD
システムの負荷の原因を切り分ける方法 - Qiita
サーバのボトルネックを探る サーバが重い時、主に以下の4つがボトルネックとなる。 CPU使用率 メモリ使用量 ディスクI/O TCPコネクション数 この記事では、これらのうちどれがボトルネックとなっているかを突き止める方法について書く。 ロードアベレージを見る まずはロードアベレージを見ることで、おおまかに問題を切り分ける。 ロードアベレージの確認方法はload averageを見てシステムの負荷を確認するに書いた。 ロードアベレージが高い場合 現在のホストの**「1. CPU使用率」**, 「2. メモリ使用率」, **「3. ディスクI/O」**を疑う。 ロードアベレージが1以下であれば軽く、1〜3くらいだとやや重く、それ以上だとこれらがボトルネックの可能性が高い。 ロードアベレージが低い場合 **「4. TCPコネクション数」**か、リモートホストがボトルネックになっていないか疑う。
NginxとApacheって何が違うの？？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Webサーバーを使うときに、NginxとApacheって言葉よく耳にしますよね。 ただその違いっていまいち良くわからなくないですか？？（僕だけだったらすみません笑） ちなみに僕は「Nginxの方がなんか人気だし良さそうな気がする。。。」という何の根拠もないイメージしか持っていませんでした。 さすがにもう少しちゃんと理解したいと思い、今回はこの違いを記事にしてみました。 ぜひぜひ最後まで読んでみてください〜！ ※ちなみにNginxとApacheはそれぞれ、「エンジンエックス」「アパッチ」と読みます。 そもそもNginxとApac
OCaml でゲームボーイエミュレータを書いた話 - Qiita
はじめに ブラウザ上で動くゲームボーイエミュレータを OCaml で書きました。以下のページで試せます。 デモページ いくつかの homebrew ROM も一緒になっているのでいろいろ遊んでみてください。おすすめは「Bouncing ball」と「Tobu Tobu Girl」です。最近のスマホならだいたい安定して 60 FPS 出るはずなので、スマホでも遊べます。 レポジトリはこちらです。 スクリーンショット なぜ OCaml でゲームボーイエミュレータ？新しいプログラミング言語を学ぶ過程で以下のように思ったことはないでしょうか？ 簡単なプログラムなら書けるが、中規模以上のコード1をどうやって書けばよいのか分からない 発展的な言語機能2も勉強しなんとなく理解した気になったが、実践のなかでどのように活用すればいいのかが分からない OCaml を本格的に勉強し始めてた数ヶ月前の筆者はまさに
自分で、でっかいベアメタル(物理)サーバーを作りたい方へ - Qiita
マンガワンのサーバー 実は過去にプレスリリースの下の方にしれっとスペックを書いたことがあります。 ベアメタルなサーバー大好きクラスタとかの人が話題にしてくれないかなーと思っていたのですが、 私が観測可能な反響は無でした。 もうこの記事の需要の無さが推測されるようではありますが、意図を解説しましょう。 Xeon Gold 6244というCPUはコア数が少なく、クロックが高く、 最近Apple M1で話題のシングルスレッドの能力が高いモデルです。 マンガワンのサーバーではCPUを4つ搭載することで、コア数の少なさをゴリ押しで解決しており、 会社のフラッグシッププロダクトらしい予算の潤沢さが伺いしれます。 また、マンガアプリなのでSSDは搭載量が多いのですが、Optaneの1.5TBを2本搭載しており、 1本を/tmpやアクセスログ、DBのトランザクション一時ファイルの置き場所に、 もう1本をマ
VHDL 100行で8bit CPUを設計してGHDLでエミュレーションする - Qiita
昔書いたにっき( https://mjt.hatenadiary.com/entry/20110125/p2 )で取り上げたMCPU( https://github.com/cpldcpu/MCPU/ )を拡張し、それなりの実用性を確保したい話。 作成したものはGitHubに置いてある https://github.com/okuoku/nanocpu 。 できたCPU 出来たCPU の諸元を簡単に要約すると、 64マクロセルCPLDに収まるギリギリのデザイン 割り込み機能なし ALU命令は 4命令のみ (ADD / NOR / Store / Jump if Clear Carry + carry clear) 8bit データ、ALU 14bit アドレスバス (8bitセグメント、6bit直接アドレス) 非同期SRAMメモリインターフェース を持つ。このCPUは64マクロセルのXil
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
