タグ

hardwareに関するoopsopsのブックマーク (10)

  • RAIDコントローラのキャッシュ構成 - とあるSIerの憂鬱

    コントローラがもっているキャッシュは『コントローラ・キャッシュ』と呼ぶ。 コントローラ・キャッシュをライト・キャッシュとして使用する場合、電源断でキャッシュ内容が消失しないよう、バッテリを内蔵する。 バッテリが無い場合、バッテリの充電が十分でない場合はライト・キャッシュを使用しないライト・スルーに自動で切り替わる。 バッテリ動作の期間内にコントローラ・キャッシュの内容を保持するだけでなく、不揮発のフラッシュ・メモリに書き込むものもある。 リード・キャッシュは効果が少ないため、HPのコントローラではリード・キャッシュ25%、ライト・キャッシュ75%の比率がデフォルト。 コントローラ・キャッシュはRAIDのパリティ計算などコントローラの作業用メモリとしても使われる。 HDD自体が持っているキャッシュ(バッファ)は『ディスク・キャッシュ』と呼ぶ。 サーバ向けのHDDではディスク・キャッシュは通常

    RAIDコントローラのキャッシュ構成 - とあるSIerの憂鬱
  • ARMアーキテクチャの高速CPU搭載、フルモデルチェンジしたOpenBlocks徹底レビュー | OSDN Magazine

    ぷらっとホームが超小型サーバー「OpenBlocks」の新モデルである「OpenBlocks Aファミリ」を発売した。OpenBlocks AファミリではARM系CPUの搭載によって処理性能が大幅に向上し、IAサーバーからの置き換えもできるという。記事ではOpenBlocks AX3を試用し、ハードウェアおよびソフトウェアの特徴やベンチマークテスト結果、使用感などを紹介する。 近年、PCの世界では体サイズの小型化が進んでいる。ビジネス向けのデスクトップPCはコンパクトなMicroATXサイズが主流で、さらに筐体が小さいものや、液晶一体型の製品も広く普及している。いっぽうサーバーの世界では、一部例外はあるものの、未だに大型の筐体が主流である。24時間、365日の稼働が前提で、またメモリやストレージなどを多く搭載する必要があるため仕方がないことなのだが、設置スペースに制限がある場合などに、

    ARMアーキテクチャの高速CPU搭載、フルモデルチェンジしたOpenBlocks徹底レビュー | OSDN Magazine
  • クラウド事業者によるサーバーハードのオープンソース化が進展 - Open Compute Summit

    クラウド事業者によるサーバーハードのオープンソース化が進展 - Open Compute Summit フェイスブック製のストレージや21インチラックが公開 米フェイスブックが中心となって設立した、サーバーハードウエアのオープンソース化を推進する団体、米オープン・コンピュート・プロジェクト(OCP)ファウンデーションが2012年5月2~3日、米テキサス州サンアントニオで「Open Compute Summit」を開催した。 同サミットでは、フェイスブックが設計したストレージや、幅が21インチという新仕様のサーバーラックなどが新たに公開されたほか、米ヒューレット・パッカード(HP)や米デルなどの大手メーカーがOCP仕様の製品を開発したことなどが明らかになった。基調講演を中心に、サミットの内容をレポートしよう。 データセンター事業者が集まってハード仕様を決定 OCPは元々、フェイスブックが自社

    クラウド事業者によるサーバーハードのオープンソース化が進展 - Open Compute Summit
    oopsops
    oopsops 2012/05/10
    剥き出しのフレームがエンジニア感を演出…
  • e1000とe1000eはそんなに違うか?~計測編~ – ひねもす庵

    GbEをベンチしてみたシリーズ数字編。 取り敢えず、画像をぺたっと。 ・・・いやね、Excelで表を作ったら、それをExportするのが面倒で。 これでも読めるからイイでしょ、ということで。 netperfのコマンドラインは以下の通り。 puddy_netperf -H 相手IP -l 30 — -s 65535 -S 65535 CPU負荷率は目測。目安程度でしかないので念のため。 CIFS計測のコマンドラインは以下の通り。 copy ¥¥相手IP¥共有名¥ファイル名 ローカルドライブ:¥作業ディレクトリ 更に、CIFS転送効率も目測。 とはいえGB単位のファイルを複数回転送していて、且つ1回目は捨てているので、そこそこの数字ではあると思う。 #1回目を捨てるのはDisk I/Oの影響が大きいため。 2回目以降は転送元側のCacheにFileが乗るので多少影響が減る。 ・・・で、数字並べ

  • MegaCLI commands

  • LSIMegaRAIDSAS – HWraid

    LSI MegaRAID SAS 1. Card information MegaRAID SAS is the current high-end RAID controllers series by LSI. It is fully hardware RAIDs controllers supporting RAID5, at least, with SAS or SATA interfaces. If you're a looking for information about MegaRAID SCSI connectors, please look at LSIMegaRAID instead. All theses card can be used with stock Linux kernel which includes a working driver. It's quit

  • クラウドを加速させるSSD技術(後編)(1/2) - @IT

    ディスクI/Oの特性を理解し、最適化へ クラウドを加速させるSSD技術(後編) 松直人 仮想化インフラストラクチャ・オペレーターズグループ チェア さくらインターネット研究所 上級研究員 2012/3/5 サーバ仮想化が普及するにつれて管理者の頭を悩ませているのが、ストレージへのアクセス集中、負荷集中です。高速にデータ処理を行えるSSDを適材適所で活用すれば、この課題に対処できます。(編集部) ディスクI/O性能の特性を理解する しばしば、「SSDはHDDに比べて高速だ」といわれますが、前編でもお話したとおり、常にそうとは限りません。特にディスク性能で違いが見られるのは「ディスクへの書き込み性能」といわれます。後編ではこれを題材として見ていきましょう。 最も簡単にディスクへの書き込み性能を測定できる対象として、「シーケンシャルWRITE」、つまり連続的にデータ書き込みを行う処理があります

  • RHEL6のマルチキューで効率的なネットワークの付加分散

    TechCenterから移行されたテクニカル リソース 2018年8月時点で、アクティブなTechCenterのコンテンツが移行され、Dell.com のDellサポートの一部になり、フォーラムがDellコミュニティに移行されました。 概要: 2018年8月時点で、アクティブなTechCenterのコンテンツが移行され、Dell.com のDellサポートの一部になり、フォーラムがDellコミュニティに移行されました。

    oopsops
    oopsops 2012/02/21
    "biosdevnameを実行してみてください。これは、デルの開発したツールで" "em[1-N]は、オンボード (埋め込み型) のNICの場合に使用します (番号はシャーシのラベルに一致します)。"
  • CentOS 6.0 で NIC と ethX の対応を固定化する

    CentOS 6.0 で NIC 交換 (オンボードの場合はマザーボード交換も含む) した場合でも、ethX が変化しないように、固定化する方法です。RHEL6 でも同様にして可能。 2015-01-18追記、CentOS7/RHEL7についてはこちらを参照。 CentOS 6.0 のデフォルトでは、MAC アドレスと ethX を対応付けており、交換により MAC が変化すると、自動的に新たな対応関係が作られるようになっているため、ethX がずれてしまいます。対応関係は、/etc/udev/rules.d/70-persistent-net.rules に設定されます。 このあたりについては、前に書いた記事を参照してください。 CentOS 6.0 で NIC 交換した場合の挙動 CentOS 6.0 で NIC と ethX の対応を変更する 以上が基礎知識ですが、まずは、この 70

    oopsops
    oopsops 2012/02/21
    OFFにしましょう… "2011-12-10追記 RHEL6.1 以降でもbiosdevnameが利用できるようです。DellマシンではデフォルトON、その他ベンダではデフォルトOFF。ブートパラメータとしてbiosdevname={0|1} を渡すことで切り替えも可能"
  • グーグルの研究が示すメモリエラーの真実--明らかになった高い発生率

    どうしてまたコンピュータがクラッシュしたのかと不思議に思ってはいないだろうか。Googleの実環境での研究によれば、それはメモリが原因かもしれないという。この研究では、メモリのエラー率が、これまでの研究で示されていたよりも高いことが分かった。 Googleは、同社のデータセンターにある膨大な数のコンピュータを使って、それらのマシンの実際の稼働状況についての実環境データを大量に収集することができる。それがまさに、エラー率が驚くほど高いことを明らかにした研究論文のために、同社が行ったことだ。 トロント大学教授Bianca Schroeder氏と、GoogleのEduardo Pinheiro氏ならびにWolf-Dietrich Weber氏の共著である同研究論文によれば、「メモリエラーの発生回数や、さまざまなDIMMにおけるエラー率の範囲が、以前報告されていたよりもずっと高いことが分かった。メ

    グーグルの研究が示すメモリエラーの真実--明らかになった高い発生率
  • 1