コンパネ−システム−仮想メモリ で設定します。(要再起動) NT では自動的に最適なサイズの物理メモリをディスク キャッシュに割り当てます（自動ワーキングセット） ので、ユーザーが調節できるのはこの程度のようです。
ケースバイケースですが、一般的に、一人で占有一つのアプリを 起動しているような場合パフォーマンスはシングル時の0.7から 0.9倍と遅くなり、マルチスレッド化したプログラムやサーバ的 な利用では、1.3から1.7倍程度らしいです。 # ちなみに，プリンタサーバとして利用しているマシンであれば， # CPUの稼働率が100%から50%づつに分散されます。
レジストリ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ftpsvc\Parameters 以下に次のエントリを手動で付加します LogAnonymous データ型 = REG_DWORD範囲 = 0または 1デフォルト = 0 (偽−成功した匿名ログオンのログは 収集しない) この値エントリは、匿名ログオンのシステムイベントログへのログ収集を有効または無効にしま す。 LogNonAnonymous データ型 = REG_DWORD範囲 = 0または 1デフォルト = 0 (偽−成功した匿名でないログオンの ログは収集しない) この値エントリは、システムイベントログへの匿名でないログオンのログ収集を有効または無効 にします。 これで，イベントログにログが残るようになります。 また，次のエントリを追加すると，テキストファイルでログが残ります。 LogFileAccess データ型 = REG_DWORD 範囲 = 0〜2 デフォルト = 0 FTPサーバーファイルアクセスのログの動作を設定します。このエントリには、次の 3つの値の うち、1つを設定します。 0 =ファイルアクセスのログを行わない (デフォルト)。 1 =ファイルアクセスのログを FTPSVC.LOGに記録する。 2 =ファイルアクセスのログを FTyymmdd.LOGに記録する。yyには現在の西暦年、mmには現在の 月、そして dd には現在の日付けが入ります。新しいログファイルは、必要に応じて開かれます。 LogFileDirectory データ型 = REG_SZ デフォルト = %SystemRoot%\SYSTEM32 ログファイルのディレクトリを指定します。ログファイルはシステムパーティションから切り離 すことができます。 これらの情報は，オンラインのヘルプに出ています。 一度，全部に目を通しておく事をお勧めいたします。（意外な発見がある）
本当に重複している場合もありますが，多くの場合のは誤報です。
イベントピューアの「ログ」−「すべてのイベントを消去」で消去することが できます。 頻繁にいっぱいになる場合は、不要なイベントについてレジストリを調整して 削除することをお勧めします。 また、「ログ」−「イベントログの設定」で「イベントログの上書き」を 「必要に応じてイベントを上書きする」に設定することで自動的に上書きさせ ることもできます。
イベントビューアのセキュリティログで各ユーザのログオン、ログオフ日時を 確認することができます。
ログを取るにはどうすればいいですか？ をご覧ください。
アスキー出版局のリソースキット、「Windows NT 3.51 アップデート」に英語版が含まれています。 また，NT 3.51 Server をお持ちでしたら，SVRTOOLに日本語対応したものが 含まれています。
経験的には、WSだと24MB程度で使ってもいいかなという気持ちに なり、40MBを越えると重いアプリを使ってもほぼ満足出来ると思います。 個人的には、NTでのメモリ増設のフィーリングは、 NTWS ：WIn95でのメモリ+8..16MB NTSv :NTWSでのメモリ+8..16MB という感じがします。但し、様々なサービスを起動するととたんに 必要メモリが増え、SQLサーバでは最低64MBという話を聞きます。 現実的には，実用運点しているシステムでは，ある程度のパフォーマンスを 維持しなければいけません。したがって，利用するアプリケーションによりますが、 特に各種サービスプログラムを使う場合は、マニュアルやパフォーマンスモニタなど により、それぞれのサービスが使用するメモリ容量を確認し、 スワップが頻繁に発生する場合には、メモリを追加する必要があります。
監査の設定を行います。 セキュリティ関連はユーザマネージャ， ファイルアクセスはファイルマネージャ， 印刷関連はプリンタマネージャ， にそれぞれ監査の設定のメニューがあります。 これ以外にも，レジストリにエントリを加えるとログが残る場合があります。 ログは基本的にバイナリファイルであり，イベントビューアでしか見れませんが， イベントビューアからテキストファイルに保存し直すことは可能です。
ロングファイル名は，ディレクトリエントリの予約領域を使い， 連続した複数のディレクトリエントリを使って実現されています。 Win3.1からですと，デフラグソフトがこの事情を理解していませんので， ロングファイル名禁止設定で利用，あるいは，8.3形式以外の名前を 使っていない自身があればいいですが， そうでない場合には，何が起こるか分かりませんので止めた方が無難です。 #ロングファイル名対応をうたっているWin95用defragなら大丈夫です。
Executive Softwareから Diskeeperという製品が販売されています。 日本では、エグゼクティブ・ソフトウェア・ジャパン TEL 03-3491-9013で 扱っています。 URL: http://www.execsoft.com/ 使用する場合は、かならず NTのバージョンおよび、サービスパックの バージョンにあわせたものを入手する必要があります。
32bitディスクアクセスでディスクアクセスそのものが高速化されても， FATの場合，ファイル数が多いと，ディスクのフラグメンテーションで パフォーマンスが目立って落ちますので，確かに気になりますね。 マシンに依ってはデフラグが必須というものもあるかもしれません。 一方，NTFSの場合には File Allocation Tableを使っていませんので， FATほどフラグメンテーションは深刻ではありません。 でも，気になる方は，デフラグのツールも市販されているようですので， 使ってみては如何でしょうか？
NTのパラレルポート経由の印刷処理は，割り込み駆動ではなく，PIO ですから，CPUの負荷は非常に高いです。 # それにしてもIDE等より圧倒的に負荷が高いですね。 回避方法として、プリントサーバを導入する方法があります。 プリントサーバを導入した場合、サーバへの負荷を大幅に減少することが できます。 また，利用率を下げるだけでしたら，Dualプロセッサのマシンに取り替える という手もあります。
理論的な速度は得られません。異なるSCSIカード上のディスク をraid0(２台並列)で構成した場合、CPUによるraidへの負荷が 増えるため、最大でも1.5〜1.8倍程度のようです。 また、SCSIバスがネックになる場合もあり、何台もつなげれば 速くなる物ではないようです。