zuntan02のはてなブログ

備忘録的なものです

NewRelicの無料プランは2017年11月14日に終了する模様

discuss.newrelic.com

機械翻訳(一部手直し)

重要:New Relic Serverと従来のアラート機能の今後の変更点

New Relic Serverと従来の警告機能は、当社の製品の1つ以上を有料で購読しているお客様のために、2018年5月15日にEOL(End-of-Life)に達します。
1つまたは複数の製品の有料購読をしていないお客様の場合、EOLの日付は2017年11月14日となります。
また、有料購読をしていないアカウントから2019年11月14日にNew Relic Alerts が削除されます。

EOLの日付の後、New RelicユーザーインターフェイスでNew Relic Serverと従来の警告機能は使用できなくなり、データ処理が停止します。また、New Relicアラートは有料アカウントでのみ利用可能で、EOLの日付から無料アカウントから削除されます。

これは簡単な決断ではありませんでしたが、実際には、お客様のニーズを満たすように設計されたより優れた機能を備えた新しい製品があり、今後はこれらの製品に投資する予定です。 New Relic Infrastructureは、昨年11月にリリースされ、構成変更の追跡、雷の高速、リアルタイムのソフトウェアインベントリ可視性、ネイティブAWSサポートなど、New Relic Serverに比べてさらに多くの利点をもたらしました。動的に変化するすべてのシステムとそれらがサポートするアプリケーションのスタックを完全に可視化できます。

同様に、従来のアラート機能で以前に利用可能だった機能は、新しいリレーショナルアラートに置き換えられ、置き換えられました。 New Relic Alertsは、より緊密に顧客の全データセットに統合され、問題をより迅速に解決するために、より広範でより深い監視を行う機能を提供します。

これらの新製品への移行をお手伝いするために、私たちは参考になることを願っています。

【postgres】JOINが多用されてて重い時はpostgresql.confのwork_memを増やそう

postgresでJOINを多用している処理が激重だったので臨時対応したメモ

【参考】

qiita.com

→work_memの最大は(実メモリ-shared_buffers)/max_connections
→work_memの経験は実メモリ/max_connections/[4-16]

PostgreSQLのチューニング その1 – Mindcircus.jp

→work_mem = 搭載メモリ / max_connections / 4

PostgreSQLパラメータ作成サイト
pgtune.leopard.in.ua



【作業メモ】

cat /var/lib/pgsql/data/postgresql.conf

max_connections = 100                   # (change requires restart)
#work_mem = 1MB                         # min 64kB

→現サーバのメモリは1GBなので
work_mem =1024/100/4 = 2.56

max_connections = 100                   # (change requires restart)
work_mem = 2MB                          # min 64kB

これだとあまりかわらなかった

max_connections = 10                    # (change requires restart)
work_mem = 25MB                         # min 64kB

これだと劇的に高速化した。

あくまで一例ですが。

■おまけ

# 現在実行中のクエリを確認
SELECT * FROM pg_stat_activity;

# 重いプロセスをkill
SELECT pg_cancel_backend(procpid);

【貧者のAWS】アカウント新規作成し続けてAWSの無料枠を使い続けたい

アカウント新規作成し続けてAWSの無料枠を使い続けたい、と思っていたけど
同じクレジットカードを使っていると1年経たずに名寄せされて標準課金される模様。

詳しくは
qiita.com



そりゃそうか。。。

PostGISのconfigureでchecking for library containing GDALAllRegister... no って言われたメモ

# What's PostGIS
# →PostGIS (ぽすとじす) は PostgreSQL データベースで地理空間情報を扱うための拡張である。
#  GNU General Public License のオープンソースソフトウェアとして配布されている。

【問題】

Chapter 2. PostGIS Installation

必須モジュールおよびバージョン
PostgreSQL 9.2 or higher
GNU C compiler (gcc)
GNU Make (gmake or make)
Proj4 reprojection library, version 4.6.0 or greater
GEOS geometry library, version 3.3 or greater
LibXML2, version 2.5.x or higher
JSON-C, version 0.9 or higher
GDAL, version 1.8 or higher

モジュール群を上記URLにある取得元からそれぞれwgetしてconfigureしてmakeしてmake installしたのち、

wget http://download.osgeo.org/postgis/source/postgis-2.3.2.tar.gz
tar -xvzf postgis-2.3.2.tar.gz
cd postgis-2.3.2
./configure

としたところ、以下のエラーとなってハマった。GDALもインストールしたのだけど。。

checking for library containing GDALAllRegister... no
configure: error: could not find GDAL

【解決】

postgisのconfig.logに

/usr/bin/ld: warning: libpq.so.5, needed by /usr/local/lib/libgdal.so, not found (try using -rpath or -rpath-link)

っていうのがあった。libpq.so.5は /usr/local/pgsql/lib の下にあったので

/etc/ld.so.conf の末尾に以下を追記

/usr/local/pgsql/lib

↓↓

 -------------- Compiler Info -------------
  C compiler:           gcc -g -O2
  SQL preprocessor:     /usr/bin/cpp -traditional-cpp -w -P

 -------------- Dependencies --------------
  GEOS config:          /usr/local/bin/geos-config
  GEOS version:         3.6.1
  GDAL config:          /usr/local/bin/gdal-config
  GDAL version:         2.2.0
  PostgreSQL config:    /usr/local/pgsql/bin/pg_config
  PostgreSQL version:   PostgreSQL 9.3.4
  PROJ4 version:        49
  Libxml2 config:       /usr/bin/xml2-config
  Libxml2 version:      2.7.6
  JSON-C support:       no
  PCRE support:         no
  PostGIS debug level:  0
  Perl:                 /usr/bin/perl

 --------------- Extensions ---------------
  PostGIS Raster:       enabled
  PostGIS Topology:     enabled
  SFCGAL support:       disabled
  Address Standardizer support:       disabled

 -------- Documentation Generation --------
  xsltproc:
  xsl style sheets:
  dblatex:
  convert:
  mathml2.dtd:          http://www.w3.org/Math/DTD/mathml2/mathml2.dtd

通った。。。

【シェルスクリプト】手動で叩いたら動くのにcron経由で動かすと動かない場合の確認方法

以下の様にして、特定ログフォルダの中身をAWS S3に同期してから日付を指定して削除するシェルスクリプトを作ってみたとき、手動で実行したら問題なく動いたのに、cronで動作すると、発火はしている様なのに、失敗している。

スクリプト本体

vi /home/hoge/bin/move-logs-s3.sh

#!/bin/sh
MYEIP=`curl -q http://169.254.169.254/latest/meta-data/public-ipv4`
S3BUCKET="S3バケット名"
OLDLOGDIR="対象ログDIR"

# s3 sync
aws s3 sync ${OLDLOGDIR} s3://${S3BUCKET}/${MYEIP}/logs --region ap-northeast-1

# tmpwatchで30日以上経過したファイルを削除
tmpwatch -m 720 ${OLDLOGDIR}

crontab

crontab -e

# move logs to S3
0 0 * * * /home/hoge/bin/move-logs-s3.sh > /dev/null 2>&1

cronのログを見るためには

MAILTO=メールアドレス
0 0 * * * /home/hoge/bin/move-logs-s3.sh

のようにして実行してみると、ログがメールで飛んでくる。
※今回はaws s3コマンドでリージョンが指定できていなかったためのエラーと分かった。上記のは修正済みです。

【AWS】(メモ)EC2インスタンスを業務後に落とし忘れないために

適切なIAMロールが付与されている or aws configureしたサーバでcrontabに以下を入れておく

# stop-instances
00 18 * * * aws ec2 stop-instances --instance-ids i-hogehoge

【さくらのクラウド】マイアーカイブからのサーバ作成時のディスク修正機能について

マイアーカイブからサーバ立てたらIPは衝突すわresolv.confは書き換えられるわでハマった。

【ひとまずの結論】

アーカイブ元のサーバでネットワークの設定をカスタマイズしている場合、そもそも[ディスク修正]機能は利用するべきではない。

□ディスク修正対象ファイルは以下にまとめられている。

cloud-news.sakura.ad.jp

3. ディスク修正機能により修正される項目(指定可能な修正項目)

例えば、スイッチ配下のインナーネットワークの端末のifcfg-eth0に

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
GATEWAY0=192.168.1.100
NETMASK=255.255.255.0
IPADDR0=192.168.1.101

みたいにセカンダリありきの書式で設定してしまっていると(CentOS7の例)、アーカイブから起動するときに「ディスク修正」で
GATEWAY=192.168.0.100
IPADDR=192.168.1.102
で書き換えを指定したとき

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
GATEWAY0=192.168.1.100
IPADDR0=192.168.1.101
GATEWAY=192.168.1.100
PREFIX=24
DNS2=210.188.224.11
IPADDR=192.168.1.102
DNS1=210.188.224.10

みたいになって、アーカイブ元のIPが生きたままになってしまい、既存サーバ群と衝突する(衝突した……)
ネットワークの設定をカスタマイズしている場合、そもそもディスクの修正機能は利用するべきではない。
逆にクラウドで運用するメリット(スケールのしやすさなど)を享受するためには、できるだけクラウド提供側の設定を遵守すべき。

4. ディスク修正機能により修正される項目(自動的に行う修正項目)

メモまで。