レンタルサーバーのDB(MySQL)がどれくらいちがうのか?SAKURAインターネットとロリポップ

ロリポップのデーターベース重すぎ。。
と思ったので、同じ金額でぜんぜんましなさくらインターネットのデータベースサーバーを比べて見ました。
書いちゃいけないことがあれば、指摘してください。
適当に選んだDBサーバーの結果なので、感覚値としてみてください。


結果としては、sakuraにしておこうって感じでした。

SAKURAインターネットのDBサーバー(MySQL)

契約はレンタルサーバーのスタンダートプランで、DBサーバーは「mysql481.db.sakura.ne.jp」でした。
6/10の時点でMySQL サーバの稼働時間は162日で、簡単にこんな感じでした。

  • トラフィック:受信5,469 GiB
  • トラフィック:送信20 TiB
  • 最大同時接続数:301
  • クエリ合計:4,197M
  • クエリ合計/時:1.08M
  • クエリ合計/分:17.98k
  • クエリ合計/秒:299.71


さくらインターネットのDBサーバーのクエリキャッシュ設定

[code language=”bash”]
SHOW VARIABLES LIKE ‘query_cache_%’

Variable_name Value
query_cache_limit 4194304
query_cache_min_res_unit 4096
query_cache_size 402653184
query_cache_type ON
query_cache_wlock_invalidate OFF
[/code]

さくらインターネットのDBサーバーのコミット設定
ロリポップのDBも同じ設定でした。

[code language=”bash”]
SHOW VARIABLES LIKE ‘innodb_flush_log_at_trx_commit%’

Variable_name Value
innodb_flush_log_at_trx_commit 1
[/code]

さくらインターネットのDBサーバーのコネクション設定
ロリポップよりMaxが多い

[code language=”bash”]
SHOW VARIABLES LIKE ‘%connections%’

Variable_name Value
max_connections 300
max_user_connections 30
[/code]

さくらインターネットのDBサーバーのバッファプール設定
ロリポップが12GBに対して、さくらは40GB。

[code language=”bash”]
SHOW VARIABLES LIKE "innodb_buffer%"

Variable_name Value
innodb_buffer_pool_instances 1
innodb_buffer_pool_size 42949672960
[/code]

ロリポは契約延長なしでいきます。

ロリポップのDBサーバー

[code language=”bash”]
SHOW VARIABLES LIKE ‘query_cache_%’

Variable_name Value
query_cache_limit 134217728
query_cache_min_res_unit 4096
query_cache_size 1073741824
query_cache_type ON
query_cache_wlock_invalidate OFF
[/code]


[code language=”bash”]
SHOW VARIABLES LIKE ‘innodb_flush_log_at_trx_commit%’

Variable_name Value
innodb_flush_log_at_trx_commit 1
[/code]



[code language=”bash”]
SHOW VARIABLES LIKE ‘%connections%’

Variable_name Value
max_connections 256
max_user_connections 30
[/code]

[code language=”bash”]
SHOW VARIABLES LIKE "innodb_buffer%"

Variable_name Value
innodb_buffer_pool_dump_at_shutdown ON
innodb_buffer_pool_dump_now OFF
innodb_buffer_pool_filename ib_buffer_pool
innodb_buffer_pool_instances 8
innodb_buffer_pool_load_abort OFF
innodb_buffer_pool_load_at_startup ON
innodb_buffer_pool_load_now OFF
innodb_buffer_pool_size 12884901888
[/code]

自分用メモ:Android:CursorのAPIまとめ by Yukiの枝折さん

eclipsが助けてくれるけど、忘れっぽいのでAndroidのCursorについて翻訳してくれているサイトをメモ

Yukiの枝折より

http://yuki312.blogspot.jp/2012/03/androidcursorapi.html


[code language=”java”]
Cursor cursor = db.selectdata();
while( cursor.moveToNext() ){
Log.d( TAG , cursor.getInt(0) );
Log.d( TAG , cursor.getString(1) );
}
[/code]

OpenSSL(Heartbleed 脆弱性) CentOS6で対策済みバージョンへアップデート( 1.0.1e-16.el6_5.7 )

管理してるサーバーでOpenSSL(Heartbleed 脆弱性) 影響があるかチェックしてみます。


OpenSSLの脆弱性Heartbleedとは?

Heartbleedのバグは、インターネット上の誰もがOpenSSLソフトウェアの脆弱なバージョンで保護されているシステムのメモリを読み取ることができます。これは、サービスプロバイダを識別するために、トラフィックを暗号化するために使用される秘密鍵、ユーザ名とパスワードと実際の内容を損なう。これは、攻撃者が、通信を盗聴サービスとユーザーから直接データを盗み、サービスとユーザーを偽装することができます。

The Heartbleed Bugより

heartbleed

影響を受けるOpenSSLバージョン

  • OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
  • OpenSSL 1.0.1g is NOT vulnerable
  • OpenSSL 1.0.0 branch is NOT vulnerable
  • OpenSSL 0.9.8 branch is NOT vulnerable

適当なサーバーで見てみたら、CentOSのバージョンによっては対象より低いバージョンでした。

[code language=”bash”]
[000@12345 ~]$ rpm -qa | grep openssl
openssl-devel-1.0.0-25.el6_3.1.x86_64
openssl-1.0.0-25.el6_3.1.x86_64
[/code]

ですがupdatesレポジトリーに修正版の「1.0.1e-16.el6_5.7」がアップされているので、適応しておきます。

[code language=”bash”]
====================================================================================================================================================================
Package Arch Version Repository Size
====================================================================================================================================================================
Updating:
openssl x86_64 1.0.1e-16.el6_5.7 updates 1.5 M
Updating for dependencies:
openssl-devel x86_64 1.0.1e-16.el6_5.7 updates 1.2 M

Transaction Summary
====================================================================================================================================================================
Upgrade 2 Package(s)
[/code]

OpenSSL Heartbleedの対策

修正バージョンへOpenSSLをアップデートして、OpenSSLライブラリ使ってるサービスを再起動!
特定できなければ、OS再起動しましょう。

Red Hatのエラータより

OpenSSLは、セキュア·ソケット·レイヤー(SSLのV2/V3 )を実装するツールキットです
トランスポート層セキュリティ(TLS v1)プロトコルだけでなく、
フル強度、汎用暗号化ライブラリ。

情報開示の欠陥がOpenSSLはTLSを取り扱い、見つかりました
DTLSハート拡張パケット。悪質なTLSまたはDTLSクライアントまたはサーバ
開示することが特別に細工されたTLSまたはDTLSハートビートパケットを送信することができます
接続されたクライアントまたはサーバからの要求あたりのメモリの限られた部分。
メモリの開示された部分は、潜在的に含まれる可能性があることに注意してください
秘密鍵などの重要な情報。 (CVE-2014 – 0160 )

Red Hatはこの問題の報告ためにOpenSSLプロジェクトに感謝したいと思います。
アップストリームは、元のようにGoogleのセキュリティのネールメータを認める
記者。

すべてのOpenSSLのユーザは、これらのアップデートパッケージにアップグレードしてくださいいる
この問題を修正するバックポートパッチを含む。更新が反映するために
効果、などのhttpdやその他などのOpenSSLライブラリにリンクされているすべてのサービス(
SSL対応のサービス)を再起動しなければならないか、システムをリブート。


Red Hatのエラータ情報はコチラhttps://rhn.redhat.com/errata/RHSA-2014-0376.html