local-search.xml

<?xml version="1.0" encoding="utf-8"?>
<search>
  
  
  
  <entry>
    <title>Nsight Compute快速上手指南（中文）</title>
    <link href="/post/ncu/"/>
    <url>/post/ncu/</url>
    
    <content type="html"><![CDATA[<link rel="stylesheet" class="aplayer-secondary-style-marker" href="/assets/css/APlayer.min.css"><script src="/assets/js/APlayer.min.js" class="aplayer-secondary-script-marker"></script><script class="meting-secondary-script-marker" src="/assets/js/Meting.min.js"></script><h3 id="Overview"><a href="#Overview" class="headerlink" title="Overview"></a>Overview</h3><p>之前经常使用的Nsight Systems是一款系统级的性能分析工具，用于分析应用程序的<strong>整体性能</strong>，使用 Nsight Systems可以了解应用程序的执行流程、确定性能瓶颈以及发现并行化的机会；而Nsight Compute与Nsight Systems不同，其是一款针对 CUDA 应用程序的<strong>内核（Kernel）级</strong>性能分析和调试工具，它专注于 GPU 上的计算性能，提供了详细的性能指标、诊断和指导，帮助开发者优化 CUDA Kernel 的性能。</p><p>简而言之，Nsight Systems主要偏向于对应用程序的整体流程进行分析，而Nsight Compute更着重于对应用程序中Launch的所有Kernel进行详细的分析。</p><p>这里是Nvidia官方提供的关于Nsight Compute的技术文档：</p><p><a href="https://docs.nvidia.com/nsight-compute/ProfilingGuide/#">Kernel Profiling Guide — NsightCompute 12.4 documentation</a></p><h3 id="安装方法"><a href="#安装方法" class="headerlink" title="安装方法"></a>安装方法</h3><p>与Nsight Systems类似，Nsight Compute可以在服务器上通过命令行指令（<strong>CLI版本</strong>）进行profiling并生成相关的分析报告，分析报告下载到本地后使用对应的<strong>GUI版本</strong>进行分析报告内容的查看。</p><h4 id="1-CLI版本"><a href="#1-CLI版本" class="headerlink" title="1. CLI版本"></a>1. CLI版本</h4><p>如果使用的是Nvidia提供的PyTorch容器镜像，则里面已经预装好了Nsight Compute，以<a href="https://docs.nvidia.com/deeplearning/frameworks/pytorch-release-notes/rel-24-03.html#rel-24-03">24.03</a>版本为例：</p><p><img src="https://img.androsheep.win/blog/Nsight_show.png" alt="Nvidia PyTorch镜像中的Nsight工具"></p><p>这时候启动容器以后可以直接使用<code>ncu</code> 指令来使用Nsight Compute。</p><h4 id="2-GUI版本"><a href="#2-GUI版本" class="headerlink" title="2. GUI版本"></a>2. GUI版本</h4><p>如果想在自己的电脑上查看dump出来的分析报告，可以前往Nvidia官网下载GUI版本的Nsight Compute，链接如下：</p><p><a href="https://developer.nvidia.com/tools-overview/nsight-compute/get-started">Getting Started with Nsight Compute</a></p><h3 id="如何运行"><a href="#如何运行" class="headerlink" title="如何运行"></a>如何运行</h3><p>Nsight Compute（或ncu）里面的一个很重要的概念就是<strong>replay</strong>，为了对待分析的应用程序获取到用户指定的性能指标，ncu可能需要多次重复运行一个Kernel才能获取到需要所有需要的指标信息：</p><blockquote><p>Depending on which metrics are to be collected, kernels might need to be <em>replayed</em> one or more times, <strong>since not all metrics can be collected in a single <em>pass</em></strong>. For example, the number of metrics originating from hardware (HW) performance counters that the GPU can collect at the same time is limited. In addition, patch-based software (SW) performance counters can have a high impact on Kernel runtime and would skew results for HW counters.</p></blockquote><p><strong>同时replay的次数是ncu根据用户设定的需要采样的指标而自动设定的，用户无法主动更改。</strong>对ncu的replay原理更详细的介绍可以参考技术文档中的<a href="https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html#replay">replay</a>一节。对一个Kernel进行多次replay的模式有很多种，可以根据replay模式不同将ncu划分成不同的运行模式（在CLI中使用ncu时可以通过参数<code>--replay-mode</code> 来指定replay的模式）。</p><h4 id="1-一般模式"><a href="#1-一般模式" class="headerlink" title="1. 一般模式"></a>1. 一般模式</h4><p>当<code>--replay-mode</code> 参数被设置为<code>kernel</code>或<code>application</code> 时，可认为ncu处于一般的profiling模式下，参考的命令行指令如下所示：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><code class="hljs bash">ncu --replay-mode kernel/application &lt;other args&gt; &lt;program to be profiled&gt;<br></code></pre></td></tr></table></figure><p>在这两个选项下，ncu会串行化进程中的所有Kernel函数来进行profiling，所以如果有需要与其他进程之间进行强制同步的Kernel函数（比如NCCL、MPI通信等），<a href="https://forums.developer.nvidia.com/t/question-about-profiling-nccl-Kernels-with-nsight-compute/185804/2?u=jiaqi-ruan">profiling的运行就有可能被卡住</a>：</p><p><img src="https://img.androsheep.win/blog/nv_response1.png" alt="Nvidia官方给出的ncu profiling特性的解释"></p><p>所以这两个选项只适合用于串行程序或者一部分不含同步的并行程序中Kernel级别的profiling。具体来说，这两个选项之间存在着一些细微的差别，假设为了采集需要的指标，ncu需要重复运行程序中的所有Kernel $N$次，则：</p><ul><li><code>kernel</code> 选项下程序只会被运行一次，但是这个程序中的所有Kernel都会被重复profiling $N$次；</li><li><code>application</code> 选项下程序会被执行$N$次，每次执行中一个程序内部的所有Kernel只会被profiling $1$次。</li></ul><p>一般来说，<code>application</code> 选项是更被推荐的选项，因为其相对于<code>Kernel</code> 选项来说在profiling时需要额外消耗的资源（比如内存等）更少，同时程序执行$1$次后也会知道一共有多少个Kernel需要被profiling。</p><h4 id="2-Range-Profiling"><a href="#2-Range-Profiling" class="headerlink" title="2. Range Profiling"></a>2. Range Profiling</h4><p>为了解决一般模式下ncu无法profiling包含同步Kernel程序的问题，Nvidia在ncu之后的版本中更新了「Range Profiling」的功能（ncu的版本需要不小于$2023.1$），其允许用户在程序需要profiling但是包含强制同步Kernel的程序段添加<strong>范围标定</strong>，然后对标定范围内的程序进行指标的profiling，下面是添加标定的范例（在<a href="https://github.com/NVIDIA/Megatron-LM">megatron</a>的<code>training.py</code>中添加）：</p><figure class="highlight python"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br></pre></td><td class="code"><pre><code class="hljs python"><span class="hljs-keyword">from</span> cofutils <span class="hljs-keyword">import</span> cofnsys<br><span class="hljs-keyword">import</span> torch<br>        <br>        <span class="hljs-keyword">if</span> is_rank_0(): <br>            <span class="hljs-comment"># 使用cofnsys或者torch提供的cuda接口都是可以的</span><br>            <span class="hljs-comment">#cofnsys.start()</span><br>            torch.cuda.cudart().cudaProfilerStart()<br><br>        loss_dict, skipped_iter, grad_norm, num_zeros_in_grad = \<br>            train_step(forward_step_func,<br>                       train_data_iterator,<br>                       model,<br>                       optimizer,<br>                       opt_param_scheduler,<br>                       config)<br>        <br>        <span class="hljs-keyword">if</span> is_rank_0(): <br>            <span class="hljs-comment">#cofnsys.stop()</span><br>            torch.cuda.cudart().cudaProfilerStop() <span class="hljs-comment"># 有开始的就一定要有结束的部分</span><br></code></pre></td></tr></table></figure><p>在标定profiling的范围之后，就可以在ncu中使用<code>--replay-mode</code> 参数中的<code>app-range</code> 来进行对标定范围内的profiling，示例代码如下：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><code class="hljs bash">ncu --replay-mode app-range &lt;other args&gt; &lt;program to be profiled&gt;<br></code></pre></td></tr></table></figure><p>需要注意的是，Range Profiling虽然允许了在profiling时不串行执行Kernels，从而可以对包含强制同步Kernel的程序进行profiling，<a href="https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html#application-range-replay">但是其最终profiling后得到的指标也将不再是Kernel级别的分析，而是对指定的range内的所有CUDA调用进行平均后的结果</a>，所以如果想对包含强制同步Kernel的程序进行Kernel级别的分析通过这条路是行不通的：</p><blockquote><p><strong>Similar to Range Replay, metrics are not associated with individual kernels but with the entire selected range.</strong> This allows the tool to execute workloads (kernels, CUDA graphs, …) without serialization and thereby supports profiling workloads that must be run concurrently for correctness or performance reasons.</p></blockquote><h4 id="3-实验性用法"><a href="#3-实验性用法" class="headerlink" title="3. 实验性用法"></a>3. 实验性用法</h4><p>为了在包含同步Kernel的程序里实现Kernel级别的profiling（虽然官方并没有提供支持），尝试利用ncu提供的参数<a href="https://docs.nvidia.com/nsight-compute/NsightComputeCli/index.html#profile">–kernel-name</a> 进行支持。<code>--kernel-name</code>参数允许在ncu的一般模式下使用<strong>正则表达式</strong>对程序中需要进行profiling的Kernel进行过滤，可以让只有名称满足正则表达式匹配的Kernel能够得到profiling，这样我们就可以手动编写正则表达式，<strong>把并行程序中需要同步的Kernel过滤掉（大多数都是通信算子，无关痛痒），只profiling其他的Kernel即可</strong>，下面提供一个过滤nccl通信函数的例子：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br></pre></td><td class="code"><pre><code class="hljs bash"><span class="hljs-comment"># 在profiling时过滤掉所有以「nc」开头的Kernel（其实就是nccl相关的函数）</span><br>ncu --replay-mode application --kernel-name <span class="hljs-string">&quot;regex:^[^n][^c].*&quot;</span> \<br>&lt;other args&gt; &lt;program to be profiled&gt;<br></code></pre></td></tr></table></figure><p>这种确实可以让包含同步Kernel的程序Kernel级别的profiling跑起来，但是有的时候会遇到程序重新跑了几次后就莫名其妙的hang在那里了，现在还在探索这个问题的解决方法。</p><h3 id="CLI重要参数介绍"><a href="#CLI重要参数介绍" class="headerlink" title="CLI重要参数介绍"></a>CLI重要参数介绍</h3><p>关于ncu在命令行运行时指定的参数详细信息可以在Nvidia提供的<a href="https://docs.nvidia.com/nsight-compute/NsightComputeCli/index.html#command-line-options">官方文档</a>中进行查看，这里对一些比较重要的参数进行介绍。</p><h4 id="1-I-x2F-O"><a href="#1-I-x2F-O" class="headerlink" title="1. I&#x2F;O"></a>1. I&#x2F;O</h4><p><code>-o</code> 参数：指定输出的分析报告<code>.ncu-rep</code> 的路径以及名称；</p><p><code>-f</code>参数：如果ncu指定了<code>-o</code> 参数、输出分析报告，分析报告指定的路径下有同名文件，可以指定<code>-f</code>参数强制将同名文件覆盖，否则ncu会报错停止运行；</p><p><code>—-log-file</code> 参数：将ncu在运行时产生的log存在指定路径的文件中；</p><p>如果在ncu运行时不指定<code>-o</code> 参数，则不会产生分析报告，并会将所有的分析结果打印在终端中，同样可以通过设置参数来决定终端中显示什么样的信息：</p><p><code>—-page</code>参数：选择在终端中打印分析报告中的哪部分信息，一般使用<code>details</code> 来打印用户指定采集的分析指标的详细信息；</p><p><code>—-csv</code>参数：将终端中打印的Kernel的分析信息组织成csv格式的输出，方便导出到文件中进行后续的数据分析。</p><p>ncu还可以使用<code>—-import</code> 将之前生成的分析报告读入，然后根据<code>—-page</code> 、<code>—-csv</code> 等参数的设置将分析报告在终端中打印出来。</p><h4 id="2-Filter"><a href="#2-Filter" class="headerlink" title="2. Filter"></a>2. Filter</h4><p>ncu在运行时可以根据参数的设置对要profiling的<strong>Kernel、进程、设备</strong>等进行过滤，首先来看Kernel的过滤：</p><p><code>—-kernel-name</code> 参数：支持根据准确名称或正则表达式来过滤需要进行profiling的Kernel</p><p><code>-c</code> 参数：限制程序中进行profiling的Kernel函数的总数</p><p><code>-s</code> 参数：跳过程序中的前$N$个Kernel后再进行profiling</p><p>再来看一些ncu对于需要进行profiling的进程进行选择的参数：</p><p><code>—-target-processes</code> 参数：选择ncu目标进行profiling的进程，<code>application-only</code> 选项只会让ncu对根进程进行profiling（然而这些根进程一般都只是启用后续的程序用的，捕捉不到什么有用的Kernel信息），<code>all</code> 选项会对根程序产生的所有子进程进行profiling，一般来说我们选择这个选项。</p><p><code>—-target-processes-filter</code> 参数：支持通过准确名称或正则表达式来过滤ncu需要进行profiling的进程，具体可以参见Nvidia文档中的说明。</p><p>最后是ncu对于需要进行profiling的设备进行选择的参数：</p><p><code>—devices</code> 参数：指定需要使用ncu进行profiling的（GPU）设备编号（默认是所有参与的GPU），<a href="https://forums.developer.nvidia.com/t/option-to-profile-only-master-process/264727/2?u=jiaqi-ruan">Nvidia官方推荐在每个Node中只使用一个设备进行profiling</a>，否则可能会引发程序的stall：</p><p><img src="https://img.androsheep.win/blog/nv_response2.png" alt="Nvidia官方对于为什么一个Node上只推荐对一个rank进行profiling的解释"></p><h4 id="3-Profile-Section"><a href="#3-Profile-Section" class="headerlink" title="3. Profile Section"></a>3. Profile Section</h4><p>使用ncu进行profiling时可以获取关于Kernel各个方面的指标，但是如果运行时需要获取所有的指标的话就可能导致ncu运行的时间非常长，如果只想获取到特定方面的指标，可以通过参数<code>—-section</code> 指定在profiling时需要采集的特定方面的指标，这样就可以有效减少不必要的profiling时间，关于所有的section的选项可以在<a href="https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html#sections-and-rules">Nvida官方文档</a>中进行查看，这里列举一些常用的section进行说明：</p><p><code>MemoryWorkloadAnalysis</code>： 可以让ncu对Kernel在内存利用方面的指标进行profiling，具体包含最大吞吐率、最大带宽利用率等指标；</p><p><code>ComputeWorkloadAnalysis</code>：Detailed analysis of the compute resources of the streaming multiprocessors (SM), including the achieved instructions per clock (IPC) and the utilization of each available pipeline. Pipelines with very high utilization might limit the overall performance.</p><p>指标示例：</p><p><img src="https://img.androsheep.win/blog/CWA_example.png" alt="CWA example"></p><p><code>Occupancy</code>：Occupancy is the ratio of the number of active warps per multiprocessor to the maximum number of possible active warps. Another way to view occupancy is the percentage of the hardware’s ability to process warps that is actively in use. Higher occupancy does not always result in higher performance, however, low occupancy always reduces the ability to hide latencies, resulting in overall performance degradation. Large discrepancies between the theoretical and the achieved occupancy during execution typically indicates highly imbalanced workloads.</p><p>指标示例：</p><p><img src="https://img.androsheep.win/blog/Occupancy_example.png" alt="Occupancy Example"></p><h3 id="使用举例"><a href="#使用举例" class="headerlink" title="使用举例"></a>使用举例</h3><h4 id="1-Profiling以及后获取csv格式报告的方法"><a href="#1-Profiling以及后获取csv格式报告的方法" class="headerlink" title="1. Profiling以及后获取csv格式报告的方法"></a>1. Profiling以及后获取csv格式报告的方法</h4><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br></pre></td><td class="code"><pre><code class="hljs bash"><span class="hljs-comment"># 在运行以下指令时ncu只会根据section的设置去捕获Kernel在内存利用方面的metrics</span><br>ncu -o <span class="hljs-built_in">test</span> -f --section <span class="hljs-string">&quot;regex:MemoryWorkloadAnalysis(_Chart|_Tables)?&quot;</span>  \<br>--target-processes all --replay-mode xx [The <span class="hljs-built_in">command</span> you want to profile]<br><br><span class="hljs-comment"># 在生成test.ncu-rep报告后，让ncu重新读入并把详细信息打印成csv格式的文件并存储</span><br>ncu -i test.ncu-rep --page details --csv --log-file test.csv<br></code></pre></td></tr></table></figure><h4 id="2-添加了许多filter条件的profiling"><a href="#2-添加了许多filter条件的profiling" class="headerlink" title="2. 添加了许多filter条件的profiling"></a>2. 添加了许多filter条件的profiling</h4><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br></pre></td><td class="code"><pre><code class="hljs bash"><span class="hljs-comment"># 以下的指令中ncu会profiling编号为0的device上的所有因为用户「command」产生的子进程中</span><br><span class="hljs-comment"># 名称为python的进程，并只会profiling这些进程中不以「nc」开头的Kernel函数</span><br>ncu -o test1 -f  --replay-mode application --target-processes all \<br>--section <span class="hljs-string">&quot;regex:MemoryWorkloadAnalysis(_Chart|_Tables)?&quot;</span>\<br>--kernel-name <span class="hljs-string">&quot;regex:^[^n][^c].*&quot;</span> --device 0 \<br>--target-processes-filter python [The <span class="hljs-built_in">command</span> you want to profile]<br></code></pre></td></tr></table></figure><h3 id="额外补充"><a href="#额外补充" class="headerlink" title="额外补充"></a>额外补充</h3><p>与Profiling产生的Overhead相关的因素（比如说加了Profiling后程序运行很长时间），在Profiling时间较长时可以从这些因素里排查原因：</p><p><a href="https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html#overhead">Kernel Profiling Guide — NsightCompute 12.4 documentation</a></p>]]></content>
    
    
    <categories>
      
      <category>科研相关</category>
      
    </categories>
    
    
    <tags>
      
      <tag>Nvidia</tag>
      
      <tag>Nsight</tag>
      
    </tags>
    
  </entry>
  
  
  
  <entry>
    <title>使用OneDrive实现Zotero的跨设备文献同步</title>
    <link href="/post/od-zotero-1/"/>
    <url>/post/od-zotero-1/</url>
    
    <content type="html"><![CDATA[<link rel="stylesheet" class="aplayer-secondary-style-marker" href="/assets/css/APlayer.min.css"><script src="/assets/js/APlayer.min.js" class="aplayer-secondary-script-marker"></script><script class="meting-secondary-script-marker" src="/assets/js/Meting.min.js"></script><h2 id="写在前面"><a href="#写在前面" class="headerlink" title="写在前面"></a>写在前面</h2><p>本篇文章是本博客第1篇关于「轻」技术方面的文章，「实用技术」这一个类别的文章主要会放一些我自己在尝试一些软件或者应用时发现的一些对我有帮助的tricks，希望也能够对大家有所裨益。</p><hr><p>众所周知，Zotero是一款被<del>广大科研人</del>频繁使用的一款开源文献管理软件，由于我也即将开始自己的研究生生涯，所以也开始使用起了这款软件。Zotero的好处可谓多多，配合其在浏览器上提供的「Zotero Connector」插件一起使用，<strong>你几乎可以存档网络上的一切文献、网页以及与其相关的元数据</strong>，并且对这些资源进行分门别类的管理以及笔记，从而构建属于自己的知识库。鉴于Zotero强大的功能和庞大的开源社群，我也同样开始使用起了这款软件。</p><p>在使用了一段时间的Zotero后，我享受到了其带来的便利的文献管理功能，但是也遇到了<strong>一定的问题</strong>。由于我有多台电脑（一台MacBook和一台PC），让Zotero在多台计算机设备之间进行数据的同步自然而然地成为了我的需求。Zotero本身同样也提供了自带的文献云同步的功能，<strong>但是供用户免费使用的额度只有300MB</strong>，如果同步的文件量超过了这一额定大小，则从最低档的$20&#x2F;year开始计费，<del>这对于一个贫穷的学生来说显然不是一件好事</del>。如果“随波逐流”地使用Zotero提供的云同步功能，则总会迎来超过免费存储额度的那一天，<strong>这一想法驱动着我去寻找其他的方法来有效地利用我已有的资源，以不增加额外花费的形式对Zotero提供的云同步进行替代</strong>。</p><p>本质上来说，Zotero的云同步功能就是把我们存放在文献库里的文献文件以及其上的注释、笔记等信息放在一个「云盘」上，这个「云盘」中的数据允许我们在各个设备上进行存取访问，所以只要找一个云盘来替代Zotero提供的「云盘」不就好了？！这个时候我便盯上了自己已经买了几年订阅的<strong>OneDrive</strong>，1T的云存储空间我才用了小几十个G，用它来做Zotero的同步再好不过了。</p><p>到此为止，我的目标就已经确定好啦，即<strong>「使用自己购买的OneDrive来对Zotero提供的云存储服务进行替代，实现跨设备之间的文献数据同步」</strong>，接下来就是找到具体的方案来完成这件事情了。在网路上也有很多人给出了使用OneDrive来对Zotero进行同步的方案，<strong>但是这些方案或多或少都存在着glitch</strong>，所以我在参考了这些方案的基础上也尝试解决它们中存在的共性问题，终于摸索出了对于我来说最为适用的完美方法XD。好啦，上面说了不少的<del>废话</del>，现在就让我们进入正题，具体地介绍这个方法是怎么实现的吧！</p><h2 id="实现方法"><a href="#实现方法" class="headerlink" title="实现方法"></a>实现方法</h2>]]></content>
    
    
    <categories>
      
      <category>实用技术</category>
      
    </categories>
    
    
    <tags>
      
      <tag>zotero</tag>
      
      <tag>onedrive</tag>
      
    </tags>
    
  </entry>
  
  
  
  <entry>
    <title>リセット</title>
    <link href="/post/reset/"/>
    <url>/post/reset/</url>
    
    <content type="html"><![CDATA[<link rel="stylesheet" class="aplayer-secondary-style-marker" href="/assets/css/APlayer.min.css"><script src="/assets/js/APlayer.min.js" class="aplayer-secondary-script-marker"></script><script class="meting-secondary-script-marker" src="/assets/js/Meting.min.js"></script>    <div id="aplayer-RunDzDYu" class="aplayer aplayer-tag-marker meting-tag-marker"         data-id="1990571322" data-server="netease" data-type="song" data-mode="circulation" data-autoplay="true" data-mutex="false" data-listmaxheight="340px" data-preload="auto" data-theme="#ad7a86"    ></div><hr><p>Hello～，这里是本博客的第一篇文章，在此热烈庆祝本博客的开张🎉🎉！！</p><p>hahaha不装了，实际上本博客最早的创建时间是在$2021$年。当时为了完成Web开发课程的大作业，就使用<code>Hexo</code>这一静态博客框架的<code>Fluid</code>主题搭建了最初版本的博客，<del>但是当时主要是以完成课程任务为目的</del>，所以在创建的过程中有很多支持博客<strong>长期运行的问题</strong>都没有想清楚就草草选择了一些方案来尝试，最后也只是弄出了一个看上去很精美但是不适合长期使用的花架子。</p><p>在之后的很长一段时间内其实都有想着把「写博客」这件事作为习惯来进行培养，毕竟既可以把学习到的东西经过整理后产生输出、转化成为真正可以供自己和他人进行参阅的知识，<del>又可以适当地在网路上发发疯</del>。但是因为种种原因（比如课业压力、Lockdown、懒惰等），<strong>这个计划一直被搁置了将近$2$年</strong>。在这$2$年的时间里我时常会想到被自己放置已久到已经荒芜的博客，甚至都有点没有脸面来面对这件事了。</p><p>直到$2023$年，我终于有了能够来重新开始记录博客的时间和耐心，并且在好友（<a href="https://shiraha.cn/">@shiraha</a>）的帮助和<del>催促</del>下，迈出了重构本博客的坚实的一步！</p><hr><p>在确定了「对博客进行重新构建」这一任务后，我花了一段时间来考虑原来的架构中什么是不够完善、需要改进的，以及怎么样才能做到让确定好的方案长期（<em>long-term</em>）运行，并且扩展性良好。总结下来后有以下几点：</p><ul><li>添加自定义域名：之前的博客是基于Github Pages来进行托管的，在没有额外配置的情况下使用的是Github提供的<code>*(github_username).github.io</code>域名，这样域名实在是有点长了，不太容易记忆，所以最好能有一个简短的域名指向本博客，能够便利游览者对本站的记忆和访问；</li><li>更换图床方案：在初始的博客版本中，我使用了<code>jsDeliver+Github仓库</code>这一常见的方案来搭建图床，<font color="#ff0000">但是现在jsDeliver已经在ToS中明令禁止用户使用其的CDN进行大量的多媒体内容分发了</font>，如果继续采用这套方案，在之后图片内容较多时有被ban的风险，<del>所以得换一些商家进行白嫖。</del></li><li>加快站点的访问速度：承接上文，之前因为是在Github Pages上托管博客，鉴于Github在中国处于一种薛定谔的状态，有的时候完全访问不了，即使能够访问的话页面加载的速度也很慢。我需要找到一种方案使国内的用户在访问本站时依然有着还可以的体验（<del>其实也就是不能让博客被🧱</del>）。</li></ul><p>在确定好要update的内容以后，经过这段时间的不懈努力，<strong>本小站终于以「近乎」达成预期效果的形式呈现在了你的面前XD</strong>，后续我也会将实现上述目标的方法作为博客po出，为自己留个存档，也给大家做个参考！</p><hr><p>没想到写着写着也有了这么多的内容，也到该结束的时候了。本文作为小站重建后的<strong>第一篇文章</strong>，意在对自己之前的经过进行一个总结，同时对美好的未来进行展望（bushi）。希望自己以后能够勇敢地去表达，把自己想说的内容留在这块「赛博自留地」，等积累了良多之后再回望时肯定会相当欣慰的吧。</p><p>以上，这里是Androidsheep，欢迎来到我的blog，和我一起玩耍和成长🥳！</p>]]></content>
    
    
    <categories>
      
      <category>余談</category>
      
    </categories>
    
    
    <tags>
      
      <tag>blog</tag>
      
    </tags>
    
  </entry>
  
  
  
  
</search>