トラブルシューティング
Nowledge Memの一般的な問題、簡単な確認、復旧手順
すべてのファイルの場所 (デスクトップ + CLI)
これはNowledge Memが使用する簡略化されたフォルダマップです:
- 設定/状態のルート:
co.nowledge.mem.desktop - データのルート:
NowledgeGraph - ユーザーワークスペース:
ai-now - クライアント側ツールのルート (
nmemCLI + OpenClawプラグイン):.nowledge-mem
~/Library/Application Support/co.nowledge.mem.desktop/ # config/state
~/Library/Application Support/NowledgeGraph/ # data (DB/index/logs)
~/ai-now/ # user workspace
~/.nowledge-mem/ # nmem/OpenClaw client configまだ表示される可能性があるレガシー互換パス:
~/Library/Application Support/nowledge-mem/~/Library/Logs/Nowledge Graph/
ログの表示
最も簡単な方法
設定 → 情報 → ログファイルを表示 を開くと、FinderまたはExplorerでログフォルダが直接表示されます。 ターミナルは不要です。
アプリの起動中にエラーが発生した場合、エラー画面に ログを表示 ボタンがあり、同じ操作ができます。
macOSでは、標準のシステムログファイルは~/Library/Application Support/NowledgeGraph/Logs/app.logにあります。
ターミナルで次のコマンドを実行すると表示できます:
open -a Console ~/Library/Application\ Support/NowledgeGraph/Logs/app.log古いビルドからアップグレードした場合、レガシーログパスがまだ残っている可能性があります:
open -a Console ~/Library/Logs/Nowledge\ Graph/app.log検索とインデックスの状態
問題が検索品質や検索インデックスのディスク使用量に関するものである場合は、まずここから始めてください:
- 設定 -> メモリ処理 -> 検索 を開きます
- 検索インデックスがディスク容量を取りすぎている場合は 最適化 を使用します
- 検索結果が明らかに不完全、古い、またはランキングがおかしい場合は インデックスを再構築 を使用します
そのパネルのストレージ行は、ローカルデータの主要な部分を分けて表示します:
- ナレッジグラフ: メモリ、エンティティ、関係、およびグラフのメタデータ
- メッセージ: 保存された会話メッセージと大きなテキストペイロード
- 検索インデックス: ランキングとスニペットに使用される、再構築可能な検索プロジェクション
これら2つの操作は異なる問題を解決します:
- 最適化 は、すべてを再構築せずにディスク上の検索ストレージを圧縮します
- インデックスを再構築 は、既存のインデックスが古くなっているか破損している可能性がある場合に、保存されたメモリ、ライブラリのコンテンツ、およびメッセージストアから検索インデックスを再作成します
Linuxサーバー上にいる場合、またはデスクトップアプリを開かずにMemをリモートで使用している場合:
nmem statusを実行して、検索の準備ができているか、再構築が必要か、またはメタデータのみを更新しているかを確認しますnmem models statusを実行すると、同じシグナルに加えてモデルのインストール状態が表示されます- ステータスが メタデータを更新中 と表示された場合は、完了するまで待ちます。 そのパスでは再構築は不要です。
古いインデックスは検索を壊しません
検索インデックスが古い場合 (たとえば、埋め込みプロバイダーやモデルを切り替えた後)、Memはエラーを出したり500を返したりしません。
インデックスが追いつく間、キーワード (FTS) 検索にフォールバックし、GET /healthはreindex_needed: trueを報告します。
準備ができたら 設定 → メモリ処理 → 検索 から再構築をトリガーしてください。
その間も検索は動作し続けます。
インデックスが最新であってもセマンティックな結果が弱く感じる場合は、GET /healthのembedding.modeを確認してください。
値がlocal-hash-fallbackの場合、実際の埋め込みモデルが設定されていないため、キーワード検索のみが完全に機能しています。
リモート埋め込みプロバイダーを設定するか、ローカルモデルをダウンロードしてセマンティック検索を復元してください。
アプリの起動に時間がかかりすぎる
症状: 起動中にアプリがハングするか、タイムアウトエラーが表示されます。
解決策: グローバルプロキシまたはVPNソフトウェアが、アプリがhttp://127.0.0.1:14242に直接アクセスするのを妨げている可能性があります。
プロキシ/VPN バイパスを設定する
プロキシまたはVPNツールを設定して、localhostアドレスをバイパスするようにします。 バイパス/除外ルールに次を追加してください:
127.0.0.1, localhost, ::1これにより、プロキシ/VPNを有効にしたまま、Nowledge Memがローカルサーバーと通信できるようになります。 バイパスルールを更新した後、Nowledge Memを再起動してください。
Windowsの起動失敗: Visual C++ ランタイムが見つからない
症状: 起動時にapp.logが次を表示します:
Import error: DLL load failed while importing _lbug- または
Backend exited during startup readiness check: exit code: 1
原因: バンドルされたデータベースエンジンに必要なMicrosoft C++ ランタイム依存関係が不足しています。
修正:
- Microsoft Visual C++ Redistributable (x64) をダウンロードしてインストールします: https://aka.ms/vs/17/release/vc_redist.x64.exe
- Nowledge Memを再起動します。
- それでも失敗する場合は、問題を報告する際に
app.logを添付してください。
Linux: 空白のウィンドウまたは遅いグラフビュー
症状: Linuxでは、Memを開くと空白または白いウィンドウが表示されます。 または、ウィンドウは機能しますが、ナレッジグラフやその他のページが非常に遅く感じられます。
原因: どちらも、LinuxでMemが使用するWebエンジンであるWebKitGTKがウィンドウを描画する方法に依存します。 一部のグラフィックス構成 (X11上のNVIDIAドライバーや一部の仮想マシンなど) では、GPUアクセラレーションによるレンダリングでウィンドウが空白になるため、Memはそこで起動時にそれをオフにします。 それがなければ、ページはCPUで描画され、高解像度画面では遅く感じられることがあります。
最初に行うこと: Memを完全に終了します。
Alt+F4またはウィンドウマネージャーの閉じるショートカットでウィンドウを閉じるか、トレイメニューから 終了 を選択します。
空白のウィンドウからは、これに約30秒、時にはそれ以上かかることがあります。
次に、pgrep -a nowledge-memが何も出力しないことを確認します。
Memがまだ実行中に渡された設定は無視されます。
空白または白いウィンドウ: GPUアクセラレーションによるレンダリングをオフにしてMemを起動します。
WEBKIT_DISABLE_DMABUF_RENDERER=1 nowledge-mem遅いページ: GPUアクセラレーションによるレンダリングをオンのままにしてMemを起動します。 この設定でウィンドウが空白になる場合は、Memを終了して通常どおり起動し直してください。
WEBKIT_DISABLE_DMABUF_RENDERER=0 nowledge-memAppImageの場合は、代わりにAppImageファイルの前に設定を置きます。
たとえばWEBKIT_DISABLE_DMABUF_RENDERER=1 ./Nowledge-Mem.AppImageのようにします。
ウィンドウにコンテンツが表示され、ナレッジグラフをドラッグまたはズームしたときにスムーズに動けば、成功です。
アプリメニューまたはログイン時の起動で設定を保持するには、セッション環境に保存してから、ログアウトして再度ログインします:
mkdir -p ~/.config/environment.d
echo 'WEBKIT_DISABLE_DMABUF_RENDERER=1' > ~/.config/environment.d/nowledge-mem.confGPUアクセラレーションによるレンダリングをオンのままにするには、1の代わりに0を使用します。
これはsystemdを使用するデスクトップで機能し、WebKitGTKを使用するすべてのアプリに適用されます。
元に戻すには、ファイルを削除してから、ログアウトして再度ログインします。
どちらの設定でも改善しない場合は、問題を報告する際にapp.logを添付してください (ログの表示を参照)。
AI Nowセッションの開始に失敗する
症状: 新しいタスク をクリックするか、一時停止したタスクを再開すると失敗し、AI Nowがセッションを開けません。
最初に行うこと: AI Nowに表示される起動診断カードを確認します。
AI Now の起動診断を使用する
起動に失敗すると、AI Nowは次の内容を含む診断カードを表示します:
- 失敗段階 (
spawn、initialize、またはnew_session) - プラットフォームとプロセスの終了コード
- 起動スクリプトからの最近の
stderr出力 - 診断を共有するためのコピーボタン
詳細 をクリックして技術フィールドを展開し、診断をコピー をクリックしてサポートまたは問題報告に使用します。
一般的な修正 (特にWindows):
- インストールが完全であることを確認します (埋め込みPythonと起動スクリプトが存在すること)。
- プラグインまたはモデル構成を変更した後、Nowledge Memを再起動します。
- Windowsを使用していて、Condaなどのシェルカスタマイズがある場合は、最新ビルドに更新します。
最近のリリースでは、AI Nowとバンドルされた
nmemランチャーが壊れたPowerShellプロファイルフックから分離されているため、それらのスクリプトがMemの起動前に失敗しなくなりました。 - バンドルされたPythonまたはPowerShellの起動をブロックする可能性のあるアンチウイルス/隔離ルールを一時的に無効にします。
- プラグインが関係している場合は、AI Now → プラグイン で期限切れのOAuthプラグインを再接続して再試行します。
オプション: Windowsで開発者コンソールを開く (ホットキー)
AI Nowがまだスタックしていて、追加の起動ログが必要な場合は、組み込みのWindowsホットキーを使用します:
- Ctrl + Shift + Iを押してTauri/WebViewコンソールを切り替えます。
- コンソール タブに移動します。
[AI Now]、[ACP]、または[kimi-cli stderr]などのキーワードでログをフィルタリングします。
これはMicrosoft StoreインストールとWebサイトインストーラービルの両方で機能します。
次に、AI Nowを開いて 新しいタスク をクリックして問題を再現します。
それでも失敗する場合は、問題を報告する際にコピーした診断とapp.logを含めてください。
モデルキャッシュの破損
症状: 検索、メモリ蒸留、またはナレッジ抽出機能が予期せず動作しなくなります。
解決策: モデルキャッシュをクリアして、モデルを再ダウンロードします。
キャッシュをクリア
設定 → モデルに移動し、次をクリックします:
キャッシュをクリアした後、必要なモデルを再ダウンロードします。
検索インデックスがディスク容量を取りすぎる
症状: 検索は機能しますが、設定 -> メモリ処理 -> 検索 の検索インデックスサイズが予想よりはるかに大きく見えます。
対処方法: 同じパネルの 最適化 をクリックします。
最適化が行うこと
最適化 はディスク上の検索インデックスを圧縮し、データベースの変更をフラッシュします。 メモリや保存された会話を削除することはありません。
v0.6.8以降、そして0.9.0で使用されるネイティブLanceDB検索インデックスではより積極的に、古いインデックスバージョンが残っているマシンでストレージを劇的に縮小できます。 実際のケースでは、ユーザーは圧縮後に5 GB -> 300 MBのような結果を見ることがあります。
使用するタイミング:
- 更新または繰り返しの再インデックス後にインデックスが増え続ける場合。
- 検索インデックスが、実際に保存しているナレッジよりはるかに大きい場合。
- 検索はまだ機能するが、ディスク使用量が明らかに無駄に見える場合。
最適化後も 検索インデックス の数値がまだおかしい場合は、インデックスを再構築 を一度実行します。メッセージ の数値が大きい場合、通常は多くの会話をインポートまたは保存したことを意味します。 インデックスファイルを手動で削除するのではなく、バックアップと移行にはデータ転送を使用してください。 ストレージが異常なままの場合は、問題を報告する際に メモリ処理 パネルのスクリーンショットを含めてください。
検索ランキングが明らかにおかしい
症状: 検索が明らかに悪い一致を返す、簡単に見つかるはずのメモリを見逃す、または以前よりずっと悪く感じられます。
対処方法: 設定 -> メモリ処理 -> 検索 を開き、インデックスを再構築 をクリックします。
インデックスの再構築が役立つ場合
再構築は、保存されたメモリ、ライブラリのコンテンツ、およびメッセージストアから完全な検索インデックスを再作成します。
これは、中断された書き込み、古いインデックス状態、またはその他のインデックス問題によって検索品質が明らかに低下した場合の正しい復旧手順です。
次の場合に試してください:
- メモリは存在するが、検索が妥当なクエリでそれを見つけられない場合。
- アップグレード、クラッシュ、または大量インポート後に結果が突然ずっと悪くなった場合。
- ランキングが、Memにすでにあるとわかっている内容と明らかに一致しない場合。
再インデックスが完了したら、同じクエリを再実行します。 ランキングがまだ明らかにおかしい場合は、問題を報告する際にクエリの例と期待されるメモリを送ってください。
Windows: インストールまたはアップグレード後にPATHが破損する
症状: Nowledge Memをインストールまたはアップグレードした後、他のコマンドラインツールが動作しなくなります。
pnpm、git、node、または同様のコマンドを実行すると、「認識されません」または「コマンドが見つかりません」が返されます。
ユーザーPATHを確認すると、C:\Users\...\Nowledge Mem\cliだけに縮小されているか、%PNPM_HOME%のようなエントリが失われています。
原因: 0.6.8より前のバージョンでは、インストール中に環境変数参照 (%PNPM_HOME%など) をリテラルパスに展開することでWindowsユーザーPATHを上書きしたり、場合によってはPATH全体をNowledge Mem CLIディレクトリだけに置き換えたりすることがありました。
これは0.6.8以降で修正されています。 インストーラーはPATHエントリとその環境変数参照を元のまま正確に保持するようになりました。
影響を受けた場合、PATHを復元する方法は次のとおりです:
- Win + Rを押し、
sysdm.cplと入力してEnterを押します。 - 詳細設定 > 環境変数 に移動します。
- ユーザー環境変数 でPathを選択し、編集 をクリックします。
- 不足しているエントリを再追加します。
一般的なものには次が含まれます:
%PNPM_HOME%%USERPROFILE%\AppData\Local\Programs\Microsoft VS Code\bin%USERPROFILE%\.cargo\bin%USERPROFILE%\AppData\Roaming\npm
- OKをクリックし、新しいターミナルウィンドウを開きます。
ヒント
PATHに何が含まれるべきかわからない場合は、動作しているマシンを確認するか、使用している各ツール (pnpm、Node.js、Rustなど) のインストールドキュメントを参照してください。 各ツールのインストーラーは通常、追加するPATHエントリを文書化しています。
Windows: 更新後にメモリが消える (ロールバック後でも)
症状: Windowsの更新後、メモリ数がゼロまたはほぼゼロに減少します。 以前のバージョンにロールバックしても戻りません。
これは、アプリが別のグラフの場所を開いたときに発生する可能性がありますが、メモリ数だけでは、以前のデータを保持しているデータベースを特定したり、それが無傷かどうかを判断したりできません。 ファイルサイズと変更時刻は、グラフを選択するための信頼できる方法ではありません。
最初に行うこと: アプリが開いていてメモリが欠落している場合は、新しいコンテンツの追加を停止して終了します (システムトレイのインスタンスも含む)。
すべてのNowledgeGraphフォルダ、データベース、ジャーナル、チェックポイント、およびバックアップをそのまま保持します。
フォルダの名前を変更したり、あるデータベースを別のものに上書きコピーしたり、個々のファイルを削除して数を変えようとしたりしないでください。
アプリのバージョン、Windowsのバージョン、起動時に表示されたエラー (ある場合)、およびグラフファイルをすでに移動または名前変更したかどうかをhello@nowledge-labs.aiまでメールでお知らせください。 データベースファイル、メモリの内容、または完全な個人パスを送る必要はありません。 サポートが、ファイルを変更するよう依頼する前に、関連するグラフと安全な復旧手順を特定します。
すでにグラフフォルダを変更した場合は、元の場所と変更後の場所の両方を、ごみ箱や既存のバックアップも含めて保持してください。 何をしたかをサポートに伝えてください。 別の交換を試みないでください。 アプリが開くこと、または数が戻ることは、それ自体では以前のすべてのメモリとスレッドが存在する証拠にはなりません。
バックエンドが起動しない、または再起動を繰り返す
トレイやメニューバーの常駐も含めてNowledge Memを終了し、同じデータを使う別のnmem-serverプロセスがないことを確認します。
0.10.96以降の安定版に更新してください。
それでも起動できない場合は、起動ログの具体的なエラーを確認します。
WALの破損を確認した場合の復旧
現在のデータベースエンジンは、データベースを開く際に.walジャーナルの変更を再適用します。
明示的なCorrupted wal fileやWALチェックサムエラーがある場合、この再適用が起動を妨げている可能性があります。
破損したWALの名前を変えて再適用の対象から外すと、本体のデータベースを開ける場合があります。
WALを読み飛ばすと最近の変更が失われる可能性があります
WALには、本体のデータベースにまだ反映されていない保存済みの変更が含まれる場合があります。
読み飛ばすと、最後に成功したチェックポイント以降のMemories、Threads、その他の変更が失われる可能性があります。
すべてのプロセスを停止した状態で、NowledgeGraphフォルダー全体を別の場所にバックアップしてください。
データベース、WAL、shadowファイル、チェックポイントのマーカー、過去のバックアップをすべて残します。
元のWALは削除しないでください。
**0.10.96以降に付属するnmem-server recover-graph**を使うと、元のファイルを残したままコピー上で復旧し、結果を検証できます。
データと互換性のある付属バックエンドを使い、先に--versionと--helpで復旧コマンドを確認してください。
これはバックエンドの実行ファイルであり、nmem CLIではありません。
付属バックエンドが見つからない場合や、ターミナルに「command not found」と表示される場合は、hello@nowledge-labs.aiにお問い合わせください。
Windowsでは付属のnmem-server.exeを使います。
PowerShellでは& "full\path\to\nmem-server.exe"の形式で実行できます。
- バックアップから、実際に使用しているデータベースを
--sourceに指定します。 以下のパスは例です。 ファイルの大きさや更新日時だけで別のデータベースを選ばないでください。 --outputには、元のデータベースディレクトリの外にある、まだ存在しない新しいディレクトリを指定します。 親ディレクトリは事前に作成しておきます。 まず厳密な復旧を試してください。
nmem-server recover-graph --source "/backup/NowledgeGraph/nowledge_graph_v2.db" --output "/recovery/attempt-1"- 厳密な復旧でWAL再適用時の具体的な破損エラーが報告され、上記のデータ損失リスクを受け入れる場合に限り、別の新しい出力ディレクトリで再試行します。
nmem-server recover-graph --source "/backup/NowledgeGraph/nowledge_graph_v2.db" --output "/recovery/attempt-2" --discard-corrupt-wal認識されたWAL破損エラーの場合、ツールは候補コピーの.walを.wal.discardedに改名して再試行します。
元のWALを削除したり、使用中のデータベースを置き換えたりはしません。
手動の改名でも再適用はスキップされますが、これらの復旧と検証の手順は行われません。
まず完全なコピーで調査してください。
元のデータディレクトリでWALを改名し、そのまま書き込みを再開しないでください。
- 成功には終了コード
0と、出力ディレクトリ内のreceipt.jsonにあるcandidate_validated_not_activatedステータスが必要です。wal_discardedがtrueかどうかを確認します。 候補はまだ有効化されていません。 元のフォルダーと復旧結果を保存し、hello@nowledge-labs.aiにお問い合わせください。 有効化を判断する前に、障害前のMemoriesとThreadsをいくつか、隔離した環境で確認する必要があります。 件数の一致や起動の成功だけでは、完全な復旧を証明できません。
WAL破損の根拠にならない起動エラー
Unreadable、LOCAL_GRAPH_ROOT_RECOVERY_REQUIRED、メモリ割り当ての失敗、ファイルロック、一般的なアサーションだけでは、WALの破損を確認できません。
チェックポイントやshadowの復旧エラー、アイデンティティ復旧マーカー、データが入った複数のグラフ保存先がある場合は、WALなどのファイルを取り除いて起動チェックを回避しないでください。
アプリとバックエンドのバージョン、OS、関連するエラーコード、変更したグラフファイルの情報をhello@nowledge-labs.aiへ送ってください。 データベースファイル、Memoryの内容、個人のフルパスは送らないでください。 すでにファイルを改名した場合は、そのファイルとフォルダー全体を残し、独断で削除したり元の名前に戻したりしないでください。 以前のデータが見つからない場合は、内容の追加や変更を止めてください。
HawDBの開発
私たちのデータベース**HawDB**はオープンソースで、現在のストレージエンジンを置き換えるために開発しています。 対応するローカルDesktop環境では実験的な設定から試せます。 それ以外の環境では、今後の安定版での置き換えをお待ちください。 移行には、読み取り可能な従来データと検証が必要です。 実験的な設定を有効にしても、破損した従来のWALは修復されません。
CLIが見つからない
症状: ターミナルでnmemを実行すると「コマンドが見つかりません」が返されます。
プラットフォーム別の解決策:
- macOS: Nowledge Memを一度開き、新しいターミナルを開きます。
アプリは起動後に
nmemをインストールまたは修復し、アプリをブロックしません。 コマンドがまだ見つからない場合は、設定 → 環境設定 → 開発者ツール → CLIをインストール を使用して手動で修復します。 - Windows: アプリのインストール後に 新しい ターミナルウィンドウを開きます (PATHの更新には新しいセッションが必要です)
- Windows (WSL): 以下のWSLセットアップセクションを参照してください
- Linux: デスクトップパッケージにはCLIが含まれており、アプリは起動後にラッパーを修復します。
新しいターミナルを開きます。
nmemがまだ見つからない場合は、~/.local/binがシェルPATHにあることを確認してください。
簡単な確認: nmem statusを実行して、CLIがNowledge Memに接続できることを確認します。
CLIとサーバーのバージョンが異なる
症状: nmem statusが「バージョンの不一致」を表示します。
これは、ターミナル内のコマンドと、それが到達したMemサーバーが別々にインストールまたは更新されたことを意味します。 接続はまだ正常である可能性がありますが、古いCLIは最新のコマンドや診断を知らない可能性があります。
古い方を修正します:
- デスクトップCLI: 設定 → 環境設定 → 開発者ツール → CLIをインストール を開き、ターミナルを再起動します。
- PyPIインストール:
python -m pip install --upgrade nmem-cliを実行します。 - pipxインストール:
pipx upgrade nmem-cliを実行します。 - 単発使用:
uvx --from nmem-cli nmem statusを実行します。 - サーバーがCLIより古い: Nowledge Memを更新または再起動するか、
NMEM_API_URLが使用する予定のサーバーを指していることを確認します。
WSLからnmemを使用する
Windows上のWSL内でClaude CodeやCodexなどのコーディングエージェントを実行する場合、Windowsのnmem CLIはLinux環境で直接利用できません。
v0.6.9以降、設定でCLIをインストール をクリックすると、デフォルトのWSLディストリビューション内に軽量なシムが自動的に作成されます。 手動でセットアップする必要がある場合は、WSLターミナルに次を貼り付けます:
mkdir -p ~/.local/bin && cat > ~/.local/bin/nmem << 'SHIMEOF'
#!/usr/bin/env bash
cd /mnt/c || exit 1
exec cmd.exe /c nmem.cmd "$@"
SHIMEOF
chmod +x ~/.local/bin/nmemこれにより、Windowsマウントされた作業ディレクトリから相互運用を介してWindowsのnmemを呼び出す薄いラッパーが作成されます。
これにより、WSLホームディレクトリからの一般的なUNCパス障害モードを回避できます。
コマンドはWindowsプロセスとして実行されるため、localhost上のデスクトップアプリに直接接続し、追加のネットワーク構成は不要です。
動作を確認します:
nmem statusシムを作成した後もnmemが見つからない場合は、~/.local/binがPATHにあることを確認してください。
Ubuntuでは自動的に行われます。
他のディストリビューションでは、export PATH="$HOME/.local/bin:$PATH"を~/.bashrcまたは~/.zshrcに追加してください。
要件
このアプローチにはWSL相互運用 (デフォルトで有効) が必要です。
/etc/wsl.confでinterop=falseまたはappendWindowsPath=falseを設定した場合は、それらを再度有効にするか、代わりにどこからでもMemにアクセスでpip install nmem-cliを使用してください。
スレッドキャプチャ
シムはnmemをWindowsプロセスとして実行するため、nmem t save --from claude-codeのようなコマンドはWSLホームではなくWindowsホームディレクトリでセッションファイルを探します。
実際にはこれは問題ありません。
デスクトップアプリは組み込みのファイルウォッチャーを通じてWSLセッションを自動的にキャプチャします。
WSLから直接CLIスレッドキャプチャが必要な場合は、代わりにpip install nmem-cliを使用してください。
nmem statusが「見つかりません」を返す
症状: リモートサーバーを使用しているときにnmem statusが「見つかりません: リソースが存在しません」を表示しますが、TUIは正常に動作します。
原因: CLIが間違ったURLにアクセスしています。
これは通常、~/.nowledge-mem/config.jsonが欠落しているか、apiUrlが間違っていることを意味します。
修正:
- 構成ファイルが存在し、正しいURLがあることを確認します:
~/.nowledge-mem/config.json { "apiUrl": "https://<your-url>", "apiKey": "nmem_..." } - curlでテストします:
curl -H "Authorization: Bearer $NMEM_API_KEY" "$NMEM_API_URL/health" - 最新の
nmemCLIに更新します。 新しいバージョンでは、より明確なエラーメッセージとリモートセットアップのヒントが表示されます。
完全なセットアップ: どこからでもMemにアクセス。
リモートアクセスが429を返す
症状: nmem statusまたはcurlが429 Too many invalid auth attemptsを返します。
解決策: クライアントが無効なAPIキーで何度も再試行しました。
- 設定 → どこからでもMemにアクセス からURL + キーを再コピーします
NMEM_API_KEYが正確な値であることを確認します (余分なスペースや引用符がないこと)- 不明な場合は、ローテーション をクリックして新しいキーを発行します
完全なセットアップと検証手順: どこからでもMemにアクセス。
リモートアクセスが401 Missing API keyを返す
症状: トンネルURLには到達できますが、nmem statusまたはcurlが401 Missing API keyを返します。
原因: 一部のネットワークプロキシが認証ヘッダーを削除します。
修正:
- 最新の
nmemに更新します (プロキシセーフなフォールバックで自動的に再試行します) - 設定 → どこからでもMemにアクセス からURL + キーを再コピーします
- 手動の
curlの場合は、次で確認します:curl "$NMEM_API_URL/health?nmem_api_key=$NMEM_API_KEY"
Memがグラフメモリが増加したと表示する
症状: より大きなライブラリで検索、グラフ、または保存操作が失敗し始め、Memがタイトルバーにグラフメモリが更新されたという通知を表示します。
原因: Memは、現在のセッションが容量を使い果たした後、次回の起動のためにグラフメモリの制限を引き上げました。 実行中のバックエンドは、アプリを再度開くまで古い制限のままです。
修正:
- Nowledge Memを終了して再度開きます。 これにより、より高いグラフメモリ制限が適用されます。
- 通知が繰り返し表示される場合は、設定 → 処理 → データベースチューニング を開き、より大きな グラフメモリ 値を選択します。
- ヘッドレスまたはサーバーインストールでは、
nmem serveを開始する前にNOWLEDGE_KUZU_BUFFER_POOL_SIZE=512MB(またはそれ以上) を設定します。
Memが大量のRAMを使用しているように見える
症状: アクティビティモニタ (macOS) またはタスクマネージャー (Windows) でNowledge Memが約1ギガバイトのメモリを使用していると表示され、ノートとメモリのアプリとしては高く見えます。
これは正常であり、その数値は誤解を招くものです。 システムモニターが表示する数値は、Memが実際に必要とするメモリ量ではありません。 そのほとんどは、マシンへの実際の負荷としてカウントされない3つのバケットに分類されます:
- すでに使い終わったメモリ。 検索、インポート、バックグラウンド処理などの作業のバースト後、オペレーティングシステムはそれらのページをすぐに回収せず、Memに駐車したままにします。 やり取りが遅いためです。 他の何かが必要とした瞬間に再利用できるよう自由です。
- 共有プログラムコード。 Memは単一の自己完結型アプリとして出荷されるため、そのプログラムコードはメモリ数値に表示されますが、共有および読み取り専用であり、システムは負荷がかかると即座にそれを破棄します。
- ディスクに保存されたナレッジ。 グラフと検索インデックスはディスク上のファイルとして存在します。 システムは高速読み取りのためにそれらをマップインするため、Memのメモリにカウントしますが、実際にはRAMに座っているわけではなく、必要に応じて解放されます。
Memの実際の作業メモリは、見出しの数値が示すよりもはるかに少なく、ローカルモデルを実行していない限り、AIモデルをメモリに保持しません。
ここですることはありません
何もする必要はありません。 マシンが本当にメモリ不足になった場合、システムはこのほとんどを自動的に回収します。 今後の更新では、Memがアイドルメモリをシステムに返す方法も変更されるため、報告される数値は自然に小さくなります。
確認したい場合の実際の測定値
約2,100のメモリの実際のライブラリで、アイドル状態で、各オペレーティングシステム独自のツールを使用して測定しました。 結論はどこでも同じです: 見出しの数値は、実際に使用中のメモリよりもはるかに大きいです。
macOS: nmem-serverプロセスに対してfootprint <pid>またはvmmap -summary <pid>で再現します:
| 内容 | サイズ |
|---|---|
報告されたメモリ (phys_footprint) | ~1024 MB |
| 共有プログラムコード (読み取り専用、回収可能) | ~281 MB |
| マップインされたデータベースファイル (ディスク上に存在) | ~0.3 MB常駐 |
| まだOSに返されていない解放済みメモリ | ~500 MB |
| 実際に使用中のメモリ | 小さな残り |
Macでは、Memはローカル埋め込みモデルをGPUで実行するため、その作業バッファはメインの数値から外れ、上記の数値はほとんど回収可能です。
使用可能なGPUがないコンピューター (一部のWindowsおよびLinuxセットアップ、またはヘッドレスサーバー) では、ローカル埋め込みモデルは代わりにCPUで実行され、より大きな作業バッファを予約するため、数値は実際にそこでは高くなります (約4-5 GBと測定)。 これは、埋め込みモデルをCPUでローカルに 実行する場合にのみ適用されます。 これを避ける最も簡単な方法は、リモート埋め込みモデル を使用することです。 これにより、このバッファがマシンから完全に外れます: Nowledge AI (Mem Plusに含まれる) はセットアップなしで機能します。 または、独自のキーで独自の埋め込みプロバイダーを接続できます。 GPUを搭載したマシンでローカルモデルを実行することも、それを小さく保ちます。 さらに、今後の更新でローカルCPUバッファを縮小しています。
Linuxサーバーのセットアップが127.0.0.1:14242に到達できないと表示する
症状: nmem license activate、nmem models download、またはnmem config ...のようなコマンドが「http://127.0.0.1:14242に到達できません」で失敗します。
原因: これらのコマンドはローカルのMemサーバーと通信します。 新しいLinuxサーバーでは、通常、サーバーがまだ実行されていないか、フォアグラウンドで起動して2番目のターミナルがまだ必要であることを忘れていることを意味します。
修正:
- 実際のサーバーの場合は、まずバックグラウンドサービスをインストールします:
sudo nmem service install --service-user <linux-user> - 次に、起動していることを確認します:
nmem service statusとnmem status nmem serveで簡単なテストだけを行う場合は、そのターミナルを開いたままにして、他のnmemコマンドを2番目のターミナルで実行します- SSH経由で自分のコンピューターからWebアプリを開くには、まず
nmem key --show-loginを実行し、それが出力する同じポートを転送します:ssh -L <port>:127.0.0.1:<port> <server>。 ログインリンクは1回だけ機能し、1分で期限切れになるため、トンネルが確立した後に新しいものを取得してください - 再度サインインするには、新しいビルドでは
nmem key --show-loginを実行して新しい単一使用ログインリンクを取得するか、古いビルドではnmem keyを実行して、出力されたキーをWebアプリに貼り付けます
