Goの長所と短所について

この記事では、あるプロジェクトをPerlからGoに書き直して得た経験を共有したいと思います。 Goの長所について多くのことが言われているため、プラスよりもマイナスの方が多くなりますが、多くの場合、新しい開発者を待っている落とし穴を見つけることができます。 断食はGo言語を叫ぶことを決して求めませんが、認めるために、私はいくつかのことを書かないことを嬉しく思います。 また、プラットフォーム全体の比較的小さなセクションについても説明します。特に、Webプログラミングや機能でよく使用されるテンプレート、正規表現、データのアンパック/パッキングなどについては何もありません。



投稿は「I PR」ハブにないため、プロジェクトの機能の概要を簡単に説明します。 これは、1日あたり約6億件のヒットを処理する高負荷のWebアプリケーションです（ピーク負荷は1秒あたり1万リクエストを超えます）。 要求の約80％はキャッシュから送信でき、残りは完全に処理する必要があります。 作業データは主にPostgreSQLに基づいており、一部はフラットな構造のバイナリファイル（つまり、実際には配列ですが、メモリではなくファイル内）です。 Perlクラスターは、パフォーマンスマージンが実際に使い果たされた8台の24台の核機で構成されていました.Goクラスターは、すでに6台になり、3つ以上の予備が確認されています。 さらに、ボトルネックはプロセッサーやOSやその他のハードウェアやソフトウェアほどではありません。バックエンドソフトウェアがどれほど強力であっても、1台のマシンで1秒間に10kの重要でない要求を処理することは物理的に簡単ではありません。

開発スピード

リファクタリング前のGoの経験は最小限でした。 1年以上、私は言語を見て、 仕様をカバーからカバーまで研究し、公式ウェブサイトなどで有用な資料を研究し、袖をまくって仕事に取りかかる準備ができていると感じました。 作業の期限の初期評価は3〜6週間でした。 作業用ベータ版は6週目の終わりに間に合うように準備ができていましたが、終わりに近づくと、もう時間がないと思い始めていました。 バグのクリーンアップとパフォーマンスの最適化にはさらに1か月かかりました。



最初は特に困難でしたが、時間が経つにつれて、仕様を次第に見なくてはならなくなり、コードはよりきれいになりました。 最初に1時間でPerlでコーディングできる機能を使用し、終日Goに費やさなければならなかった場合、このギャップは大幅に狭まりました。 しかし、とにかく、GoでのプログラミングはPerlのプログラミングよりもかなり長くなります。作業に必要な構造、データ型、インターフェースを考え、コードですべて記述し、スライス、マップ、チャネルの初期化を行い、nilのチェックを記述しなければなりません...これにより、すべてがはるかに単純になります。構造体にハッシュを使用する必要があり、以前にフィールドを宣言する必要がなく、プログラマーにとってより多くの構文糖衣があります。 少なくとも並べ替えを比較する-Goでは、データ比較のためにクロージャーを指定する方法はありません。長さを取得するために個別の関数を登録する必要があります。また、インデックス比較関数に加えて、配列内の場所で要素を交換するために別個の関数を記述する必要もあります そして、なぜですか？ ジェネリックがないため、ソート関数は、何が入り込んだのか、この値の交換をどのようにオフセットするのかを把握するよりも、特別に宣言されたSwap（i、j）を呼び出す方が簡単です。



並べ替えに加えて、/ while（）{...} continue {...}のPerlコンストラクトの欠如にも感銘を受けました（現在の反復が次の演算子によって早期に中断されても、 continueブロックが実行されます）。 Goでは、非正規のgotoを使用する必要があります。これは、ジャンプラベルの後に使用されないものも含めて 、その前にすべての変数宣言を記述することを強制します。

var cnt int for ;; { goto NEXT a := int(0) // ./main.go:16: goto NEXT jumps over declaration of a at ./main.go:17 cnt += a NEXT: cnt ++ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、ポインターと非ポインターの構文統一のパラダイムは機能しません-構造体を使用する場合、コンパイラーは同じ構文を使用する機会を与え、マップにも-ブラケットを逆参照して使用する必要がありますが、コンパイラーはすべてを決定できます：

 type T struct { cnt int } s := T{} p := new(T) s.cnt ++ p.cnt ++
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

でも

 m := make(map[int]T) p := new(map[int]T) *p = make(map[int]T) m[1] = T{} (*p)[1] = T{} p[1] = T{} // ./main.go:13: invalid operation: p[1] (type *map[int]T does not support indexing)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すでに作業の終わりに、最初のアーキテクチャが間違っていたため、最初に実装された機能の一部を書き換えるのに時間を費やす必要がありました。 得られた経験は新しいアーキテクチャのパラダイムを提供しますが、この経験はまだ得られる必要があります））



ちなみに、文字のコードの総量はほぼ一致していました（Perlのスペースアラインメントの場合にのみ2つのスペースが使用され、Goでは1タブ）、Goの行は20％増えました。 確かに、機能はわずかに異なります。Goでは、たとえばGCでの作業が追加されますが、Perlでは、外部ファイルキャッシュにSQLクエリをキャッシュするために別のライブラリが考慮されます（mmap（）経由のアクセス）。 一般に、コードの量はほぼ同じですが、Perlはまだ少しコンパクトです。 しかし、Goには括弧とセミコロンが少ない-コードはより簡潔で読みやすいように見えます。



一般に、Goコードは非常に迅速かつ正確に記述されており、たとえばC / C ++よりはるかに高速ですが、特別なパフォーマンス要件のない単純なタスクの場合は、Perlを引き続き使用します。

性能

率直に言って、パフォーマンスに関してGoについて特に不満はありませんが、もっと期待しています。 Perlとの違い（算術では、計算の種類に大きく依存します。たとえば、Perlはまったく輝きません）は約5〜10倍です。 私はgccgoを試す機会がありませんでした。 FreeBSDでは難しくありませんが、残念です。 しかし、バックエンドソフトウェアはボトルネックではなくなり、CPU消費は1コアの約50％になり、負荷が増加すると、Nginx、PostgreSQL、OSで最初に問題が発生します。



パフォーマンスを最適化する過程で、プロファイラーは、コードに加えて、ランタイムがCPUのアクティブな部分を消費することを示しました（これはランタイムパッケージに関するだけではありません）。

top10 --cumの例を次に示します。

 Total: 1945 samples 0 0.0% 0.0% 1309 67.3% runtime.gosched0 1 0.1% 0.1% 1152 59.2% bitbucket.org/mjl/scgi.func·002 1 0.1% 0.1% 1151 59.2% bitbucket.org/mjl/scgi.serve 0 0.0% 0.1% 953 49.0% net/http.HandlerFunc.ServeHTTP 3 0.2% 0.3% 952 48.9% main.ProcessHttpRequest 1 0.1% 0.3% 535 27.5% main.ProcessHttpRequestFromCache 0 0.0% 0.3% 418 21.5% main.ProcessHttpRequestFromDb 16 0.8% 1.1% 387 19.9% main.(*RequestRecord).SelectServerInDc 0 0.0% 1.1% 367 18.9% System 0 0.0% 1.1% 268 13.8% GC
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、消費されたCPUの49％のみがハンドラーによる実際のscgiリクエストの処理に費やされ、33％がシステム+ GCに費やされています



そして、同じプロファイルのtop20を次に示します。

 Total: 1945 samples 179 9.2% 9.2% 186 9.6% syscall.Syscall 117 6.0% 15.2% 117 6.0% runtime.MSpan_Sweep 114 5.9% 21.1% 114 5.9% runtime.kevent 93 4.8% 25.9% 96 4.9% runtime.cgocall 93 4.8% 30.6% 93 4.8% runtime.sys_umtx_op 67 3.4% 34.1% 152 7.8% runtime.mallocgc 63 3.2% 37.3% 63 3.2% runtime.duffcopy 56 2.9% 40.2% 99 5.1% hash_insert 56 2.9% 43.1% 56 2.9% scanblock 53 2.7% 45.8% 53 2.7% runtime.usleep 39 2.0% 47.8% 39 2.0% markonly 36 1.9% 49.7% 41 2.1% runtime.mapaccess2_fast32 28 1.4% 51.1% 28 1.4% runtime.casp 25 1.3% 52.4% 34 1.7% hash_init 23 1.2% 53.6% 23 1.2% hash_next 22 1.1% 54.7% 22 1.1% flushptrbuf 22 1.1% 55.8% 22 1.1% runtime.xchg 21 1.1% 56.9% 29 1.5% runtime.mapaccess1_fast32 21 1.1% 58.0% 21 1.1% settype 20 1.0% 59.0% 31 1.6% runtime.mapaccess1_faststr
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私のコードの計算は、ランタイムが処理しなければならないタスクのバックグラウンドに対して単純に失われます（しかし、そうすべきである、私は難しい数学を持っていません）。



私見、コンパイラとライブラリを最適化するための大きな予備がまだあります。 たとえば、インライン化に気付きませんでした-すべてのmutexはgoroutinスタックのスイープで完全に表示されます。 コンパイラーの最適化プロセスはまだ止まりません（それほど前ではありませんが、例えばDmitry Vyukovはチャンネルの実装を大幅に加速しました ）が、これまでのところカーディナルシフトはあまり目立ちません。 たとえば、Go 1.2からGo 1.3に切り替えた後、パフォーマンスの違いはほとんど見られませんでした。



最適化中であっても、math / randパッケージを放棄する必要がありました。 事実、クエリ処理中に擬似乱数が必要になることが多かったのですが、データバインディングではrand.Seed（）がCPUを使いすぎていました（プロファイラーは全体の13％を示しました）。 それを必要とする人は誰でも高速シード（）で擬似乱数を生成する方法をグーグルで検索しますが、それでも暗号化の目的で暗号化/ランドパッケージがあり、数学/ランドでは初期化中に高品質のビットミキシングをそれほど気にしないかもしれません。

ところで、私は次のアルゴリズムに焦点を当てることになりました。

 func RandFloat64(seed uint64) float64 { seed ^= seed >> 12 seed ^= seed << 25 seed ^= seed >> 27 return float64((seed*2685821657736338717)&0x7fffffffffffffff) / (1 << 63) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Perlでは、すべての計算が1つのプロセスで行われ、個別のワーカープロセスが使用され、memcachedを介したもの、ファイルを介したものなど、共通のキャッシュを整理する必要があったのは非常に便利です。 Goでは、これははるかに単純で自然です。 しかし、現在、外部キャッシュがない場合、コールドスタートの問題が発生し、ここで少し手を加えなければなりませんでした-最初は、nginxに制限しようとしました（一度に10万のゴルーチンが開始され、全体が起きないように） https：//モジュールを介した同時要求の数github.com/cfsego/nginx-limit-upstream 、しかしそれは非常に安定して動作しませんでした（接続プールが詰まると、負荷を除去した後でも通常モードに戻るのが多少困難でした）。 その結果、scgiモジュールに少しパッチを適用し、同時に実行されるリクエストの数にリミッターを追加しました-現在のリクエストの一部が処理されるまで、新しいリクエストはAccept（）で受け入れられません-th：

 func ServeLimited(l net.Listener, handler http.Handler, limit int) error { if limit <= 0 { Serve(l, handler) } if l == nil { var err error l, err = net.FileListener(os.Stdin) if err != nil { return err } defer l.Close() } if handler == nil { handler = http.DefaultServeMux } sem := make(chan struct{}, limit) for { sem <- struct{}{} rw, err := l.Accept() if err != nil { return err } go func(rw net.Conn) { serve(rw, handler) <-sem }(rw) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

scgiモジュールもパフォーマンス上の理由で選択されました-何らかの理由で、net / http / fcgiは単なるnet / httpよりも遅く（永続的な接続をサポートしません）、net / httpはさらにtcpパケットの生成と内部tcp接続のサポートでOSをロードしました（技術的にはUNIXソケットでリッスンを開始することは可能ですが）-そして、それを取り除くことができたので、なぜそれを取り除きませんか？ nginxをフロントエンドとして使用すると、タイムアウト制御、ログ記録、失敗したリクエストをクラスターから他のサーバーに転送するなど、最小限のサーバー負荷ですべての利点が得られます。 このアプローチのもう1つのプラス-netstat -Lanによれば、Acciキューがscgiソケットで増大することを確認できます。これは、どこかにオーバーロードがあり、何かをする必要があることを意味します。

コード品質とデバッグ

net / http / pprofパッケージは魔法のようなものです！ これは、Apache server-statusモジュールに似ていますが、Goデーモン用です。 ところで、専用のhttpハンドラーの代わりにDefaultServeMuxを使用する場合は、link / debug / pprof /を介してすべてのユーザーがパッケージを利用できるようになるため、実稼働環境に含めることはお勧めしません。 それどころか、http経由でパッケージ関数にアクセスするには、localhostで別のミニサーバーを実行する必要があります。

 go func() { log.Println(http.ListenAndServe("127.0.0.1:8081", nil)) }()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このモジュールは、プロセッサとメモリのプロファイルを取得することに加えて、現在実行中のすべてのゴルーチンのリスト、それらで現在実行されている機能のチェーン全体、および状態を表示することを可能にします：/ debug / pprof / goroutine \？さまざまなゴルーチンとその状態のリスト、および/ debug / pprof / goroutine \？debug = 2は、実行中のすべてのゴルーチンのリストを提供します。 複製（つまり、完全に同一の状態）。 それらの1つの例を次に示します。

 goroutine 85 [IO wait]: net.runtime_pollWait(0x800c71b38, 0x72, 0x0) /usr/local/go/src/pkg/runtime/netpoll.goc:146 +0x66 net.(*pollDesc).Wait(0xc20848daa0, 0x72, 0x0, 0x0) /usr/local/go/src/pkg/net/fd_poll_runtime.go:84 +0x46 net.(*pollDesc).WaitRead(0xc20848daa0, 0x0, 0x0) /usr/local/go/src/pkg/net/fd_poll_runtime.go:89 +0x42 net.(*netFD).accept(0xc20848da40, 0x8df378, 0x0, 0x800c6c518, 0x23) /usr/local/go/src/pkg/net/fd_unix.go:409 +0x343 net.(*UnixListener).AcceptUnix(0xc208273880, 0x8019acea8, 0x0, 0x0) /usr/local/go/src/pkg/net/unixsock_posix.go:293 +0x73 net.(*UnixListener).Accept(0xc208273880, 0x0, 0x0, 0x0, 0x0) /usr/local/go/src/pkg/net/unixsock_posix.go:304 +0x4b bitbucket.org/mjl/scgi.ServeLimited(0x800c7ec58, 0xc208273880, 0x800c6c898, 0x8df178, 0x1f4, 0x0, 0x0) /home/user/go/src/bitbucket.org/mjl/scgi/scgi.go:177 +0x20d main.func<C2><B7>008() /home/user/repo/main.go:264 +0x90 created by main.main /home/user/repo/main.go:265 +0x1f5c
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、ロックのあるバグを特定することができました（特定の条件下では、RUnlock（）が2回呼び出されましたが、これを行うことはできません）-スタックのダンプで、ロックされたゴルーチンとRUnlock（）が呼び出された行番号の束を見ました。



CPUプロファイルも悪くありません。gv（ghostview）をインストールし、カウンターを使用した関数間の遷移のXorgダイアグラムを確認することをお勧めします。注意して最適化する必要があるものを確認できます。



有用なユーティリティですが、私の主な利点は、あらゆる種類のprintf（）のフォーマット指定子が見つからないという警告になりました-コンパイラはこれを検出できません。 明らかに悪いコード

 if UintValue < 0 { DoSomething() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

獣医はまったく反応しません。



コード検証の主な作業は、コンパイラーによって実行されます。 彼は未使用の変数とパッケージを定期的に誓いますが、コンパイラーも獣医も構造内の未使用フィールドに反応しません（少なくとも警告はあります）。



演算子には注意が必要です：= 。 2つのuintの差を計算する必要がある場合がありました。 負の差を負と正しく見なし、コード

  var a, b uint ... diff := a - b
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

あなたが期待するものではない-あなたは署名された型への変換を使用する必要があります（または署名なしを使用しない）



同じデータ型に異なる目的で異なる名前を付けることもお勧めします。 たとえば、次のように：

 type ServerIdType uint32 type CustomerIdType uint32 var ServerId ServerIdType var CustomerId CustomerIdType
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして今、CustomerId変数については、uint32内に存在するにもかかわらず、コンパイラはServerIdの値を（タイプ変換なしで）書き込むことを許可しません。 特に変数を初期化する場合は、型キャストを使用する必要がありますが、あらゆるタイプミスに役立ちます。

パッケージ、ライブラリ、およびCの束

Goの人気で重要な役割を果たしたのは、Cライブラリと対話するための効果的な（パフォーマンスの面ではなく、いくつかの問題が残っている）メカニズムです。 概して、Goライブラリの重要な部分は、対応するCライブラリの単なるラッパーです。 たとえば、github.com / abh / geoipおよびgithub.com/jbarham/gopgsqldriverパッケージは、それぞれ-lGeoIPおよび-lpqでコンパイルします（実際には、ネイティブのGo PostgreSQLドライバー-github.com/lib/pqを使用します）。



たとえば、unistd.hのほぼ標準のcrypt（）関数を考えてみましょう-この関数は多くの言語、たとえばNginx Perlモジュールではすぐに使用でき、追加のモジュールをロードせずに使用できます。これは便利です。 しかし、Goでは、ここでは自分でCに転送する必要があります。 これは基本的な方法で行われます（例では、結果からソルトがカットされます）。

 // #cgo LDFLAGS: -lcrypt // #include <unistd.h> // #include <stdlib.h> import "C" import ( "sync" "unsafe" ) var cryptMutex sync.Mutex func Crypt(str, salt string) string { cryptStr := C.CString(str) cryptSalt := C.CString(salt) cryptMutex.Lock() key := C.GoString(C.crypt(cryptStr, cryptSalt))[len(salt):] cryptMutex.Unlock() C.free(unsafe.Pointer(cryptStr)) C.free(unsafe.Pointer(cryptSalt)) return key }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ロックが必要です crypt（）は同じchar *を内部状態に返します。受信した文字列はコピーする必要があります。そうでない場合、次の呼び出し中に上書きされます。 関数はスレッドセーフではありません。

データベース/ SQL

使用されている各Dbハンドラーについて、呼び出して接続の最大制限を登録し、アイドル接続のゼロ以外の制限を指定することをお勧めします。

 db.SetMaxOpenConns(30) db.SetMaxIdleConns(8)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1つ目はデータベースの過負荷を回避し、最大パフォーマンスモードで使用します（同時接続数の増加に伴い、データベースのパフォーマンスはある時点から低下し始め、同時要求数に最適な値があります）、2つ目は新しい接続を開く必要性を取り除きますすべてのクエリ、fork（）モードのPostgreSQLでは、これは特に重要です。 もちろん、PostgreSQLの場合は、まだpgpoolまたはpgbouncerを使用できますが、これはカーネルによるデータ送信と追加の遅延のための余分なオーバーヘッドです。したがって、アプリケーションレベルで接続の継続性を確保することをお勧めします。



リクエストの解析と計画の構築のオーバーヘッドを除外するには、直接リクエストの代わりに準備済みステートメントを使用する必要があります。 ただし、覚えておく必要があります-場合によっては、クエリ実行スケジューラは、最適なプランを使用しない場合があります。これは、リクエストの実行段階ではなく、リクエストの解析段階で構築され、スケジューラには、使用するのに適したインデックスを知るための十分なデータがない場合があるためです ところで、PostgreSQL Goドライバーの変数のプレースホルダーは、Perlのように、「？」の代わりに「$ 1」、「$ 2」などを使用します。



sql。（行）.Scan（）には1つの機能があります-DomainNameType stringなどの名前が変更された文字列タイプを認識しません。 文字列型の一時変数を開始し、データベースからデータをロードしてから、型変換を使用して割り当てを行う必要があります。 何らかの理由で、名前が変更された数値型にはこのような問題はありません。

チャンネルと同期

Goにはチャネルがあるので、それだけを使用する価値があるという誤った意見があります。 これは完全に真実ではありません-各タスクには独自のツールがあります。 チャネルはさまざまな種類のメッセージを送信するのに最適ですが、sql-cacheなどの共有リソースを操作する場合は、ミューテックスを使用することは非常に合法です。 チャネルを介してキャッシュを操作するには、1つのコアへのキャッシュアクセスのパフォーマンスを制限するクエリマネージャーを作成し、シェデラーゴルーチンにさらに作業を追加し、チャネルにデータをコピーおよび読み取るためのオーバーヘッドを追加する必要があります。さらに、データ転送用の一時チャネルを作成する必要がありますバックコール機能。 また、チャネルを使用するコードは、mutexを使用したコードの何倍も複雑になります（奇妙なことに）。 しかし、ミューテックスでは、デッドロックに陥らないように非常に注意する必要があります。



Goにはstruct {}のような扱いにくい機能があります。 つまり 完全に空の構造、ボーダーレス。 それはゼロスペースを占有し、そのような構造の任意のサイズの配列もゼロスペースを占有し、空の構造のバッファリングされたチャンネルもゼロスペースを占有します（もちろん内部データも）。 実際、空の構造のこのバッファリングされたチャネルはセマフォであり、コンパイラで別のハンドラが作成されます-Go構文のセマフォが必要な場合は、 chan struct {}を使用できます。



同期パケットの悲しみは少し悲しいです。 たとえば、スピンロックはありませんが、高速であるため非常に便利ですが（GCを使用する場合、スピンロックの使用はリスクのあるビジネスになります）。 さらに、ミューテックス自体の操作はインラインではありません（私が知る限り）。 さらにイライラするのは、RWMutexロックをアップグレードできないことです-ロックがRLockステータスにあり、変更が必要であることが判明した場合-RUnlock（）、Lock（）を実行し、これらの変更または何らかのゴルーチンの必要性がまだあるかどうかを再度確認してください何とかできました。 ノンブロッキングのTryLock（）関数もありません。なぜかは明確ではありません-場合によっては非常に必要です。 ここでは、言語の開発者である「プログラムの必要性をよく知っています」IMHOが既に行き過ぎています。



場合によっては、アトミック操作を含むsync / atomicパッケージは、ミューテックスの使用を回避するのに役立ちます。 たとえば、コードで現在のuint32タイムスタンプを使用することがよくあります。グローバル変数に保持し、各リクエストの最初に現在の値をアトミックに保存します。 少し汚いアプローチ、ヘルパー関数を書くことは可能でしたが、パフォーマンスのためにそのような犠牲を払わなければならないことがあります-特別な制限なしでこの変数を算術式で使用できるようになりました。



一部の共通データが1か所でのみ（たとえば定期的に）更新される場合や、読み取り専用モードで使用される場合には、別の適切な最適化方法があります。 一番下の行は、読み取り操作のためにRLock（）/ RUnlock（）を行う必要がないことです（および更新のためにLock（）/ Unlock（））-更新機能はデータを新しいメモリ領域にロードしてから、古いデータへのポインターをポインターでアトミックに置き換えることができます新しいものに。 確かに、Goでは、アトミックポインター書き込みの機能にはunsafe.Pointer型が必要であり、この設計をブロックする必要があります。

 atomic.StorePointer((*unsafe.Pointer)(unsafe.Pointer(&Data)), unsafe.Pointer(&newData))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、ロックを心配することなく、式でこのデータを使用できます。 これはGoにとって特に重要です。 一見短いロックは、実際には非常に長くなる可能性がありますが、これはすべてGCが原因です。

GC（ガベージコレクター）

彼は私の屋根をかなり飲みました;（。状況を想像してください-負荷テストを実行して-すべては大丈夫です。ライブトラフィックをしましょう-すべてがうまくいきます。それからバム-そしてすべてが悪くなるか、非常に悪いです-古い要求がハングし、新しい要求が到着し（毎秒数千）、アプリケーションを再起動する必要があります。その後、キャッシュを補充する必要があるため、すべてが再び停止しますが、少なくとも機能し、しばらくしてから正常に戻ります。それぞれの実行時間を測定しました要求処理段階-およびvi ロックを使用しないステージでもデータベースやファイルへのアクセスは使用せず、ローカル計算のみを実行し、通常はマイクロ秒に収まるように、すべてのステージの実行時間が定期的に3秒以上にジャンプすることを望みます。それは何らかの外的要因ではなく、プラットフォーム自体、またはむしろガベージコレクターでした。



Goでは、runtime / debug.ReadGCStats（）を介してGCパフォーマンス統計を表示できるのは良いことです。驚くべきことがあります。 私の場合、最もアンロードされたサーバーでは、GCは次のモードで機能しました。

0.06

0.30

2.00

0.06

0.30

2.00

...

数値自体はわずかに異なりますが、大きさの順序は保持されます。 これは、GCの実行中にアプリケーションがスリープ状態になる期間であり、最新のものが最上部にあります。 すべての作業を2秒間一時停止します-何ですか？ 最も忙しいサーバーで何が起こっているのか想像することすら恐れていますが、余分なダウンタイムが発生しないようにそれらに触れませんでした。



解決策は、GC（）をより頻繁に実行することです。信頼性のために、プログラムから独立する方が良いです。 定期的にでもできますが、少し混乱してリクエストカウンターを作成し、古いデータの主要なクリーンアップ後に強制的にGC（）を起動しました。その結果、GC（）は数分に1回ではなく、10〜20秒ごとに実行を開始しましたが、各パスは約0.1秒で安定しており、まったく別の問題です。同時に、デーモンのメモリ消費量が20％減少しました。ガベージコレクターを完全に無効にするオプションがありますが、これは短命のプログラムにのみ適しており、デーモンには適していません。言語開発者はGCに設定を追加して、指定された制限よりも長くアプリケーションを停止しないで、代わりに頻繁に実行を開始する必要があります。これにより、高負荷の問題から多くのユーザーを節約できます。

地図

マップ（Perlに関してハッシュ）が非常に有用なものであると主張する人はいません。しかし、私は言語開発者に対して、それらの実装と使用方法について深刻な不満を持っています。大まかに言って、マップコンパイラを使用するには、次の3つの関数を使用します。

 valueType, ok := map_fetch(keyType) map_store(keyType, valueType) map_delete(keyType)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

. — , (.. , , ) —

 type T struct { cnt int } m := make(map[int]T) m[0] = T{} m[0].cnt++ // ./main.go:9: cannot assign to m[0].cnt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

m[0], cnt .

 m := make(map[int]*T) m[0] = new(T) m[0].cnt++
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 m := make(map[int]T) tmp := m[0] tmp.cnt++ m[0] = tmp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, — ( )



, , map_store

 *valueType = map_allocate(keyType)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マップに追加された値がメモリ内で移動しないという制限を追加します。



map_allocate関数は、新しく作成された要素だけでなく、変更される場合は既存の要素へのポインタを取得するために使用する必要があります。このポインターを使用して、プログラマーに戻り、値を更新し、参照メソッドを呼び出します。値が設定されている間は、すべて正常に機能します。



マップ内の値への参照を取得する機能は、すぐに実証されているすべての言語セキュリティを破壊すると主張する人もいます。しかし、マップの場合、セキュリティはとにかく保証されません-ブロックせずに異なるゴルーチンから使用することはできません。そうしないと、要素の挿入中に内部データを破壊するリスクがあります。さらに、プログラマに安全でないパッケージを使用せずにマップ要素のアドレスを取得する必要があると言う人はいません-上記の例では、コンパイラはアドレスを取得し、カウンタをインクリメントし、そのアドレスを忘れることができます-それは他のどこにも取得できず、原則としてこれから誰も取得しません操作は影響を受けません。



問題が発生するのは、アイテムを削除し、未使用のメモリへのリンクを引き続き使用する場合のみです。これは、ブロックなしで異なるゴルーチンからのマップを同時に使用するのと同じ領域からです-プログラマーがピノキオ自身である場合、彼の医者は誰ですか？また、プログラムが削除されたアイテムへのライブリンクを持っている限り、削除後にメモリが解放されないように、ガベージコレクターをこの場合に適合させることができる場合、すべてが正常であり、セキュリティ上の問題はありません。

まとめ

悲しいかな、世界には完璧はありません。しかし、新しい言語がすぐに理想的に生まれることを期待するのは単純です。はい、Goにはいくつかの欠点がありますが、原則としてそれらはすべて修正可能であり、要望があります。しかし、Goはプログラミング言語の開発を次のレベルに進め、マルチコアコンピューターアーキテクチャの現代の現実に適応し、適切なパラダイムを提案しています。



非常に長い間、私は新しいプログラミング言語を勉強していません。かつて、私はC（FreeBSDカーネルにパッチを当てるためのビットのレベル）、Perlおよびシェルスクリプト（一般的なタスク用）を少し習得しました。Python、Ruby、JSの学習に没頭する時間も欲望もありませんでした。これらの言語は根本的に新しいものを提供できず、アイデアを変えたいという欲求もありませんでした。Goは私のツールセットを大幅に補完することができました。彼のすべての欠点について、私はそれを勉強するのに費やした時間を一滴も後悔していません-それは本当に価値があります。