202502

《事实》：帮助你识别人类的十大情绪化本能，避免情绪化决策
https://zhuanlan.zhihu.com/p/692413757

ES 分片不均衡

问：elasticsearch中有A,B,C 3个节点，现在新增加了一个D节点，删除了C节点。一个索引有10个分片，并开启了一个副本分片，目前集群的状态仍然是绿色的，但是A,B,D这3个节点上的分片不均匀，A节点上全是主分片，B节点上全是副本分片，D节点上主分片和副本分片。
这时候如果A节点宕机，集群就会变成红色，如何避免这种情况。

思考：嗯，我现在遇到了一个关于Elasticsearch集群的问题，需要仔细思考一下怎么解决。让我先理清楚问题的具体情况。

用户有一个Elasticsearch集群，原本有三个节点A、B、C。后来新增了节点D，并移除了节点C。现在集群里有A、B、D三个节点。一个索引有10个主分片，每个主分片有一个副本分片，所以总共有20个分片（10主+10副本）。目前集群状态是绿色的，但分片分布不均匀：A节点全是主分片，B节点全是副本分片，D节点既有主分片也有副本分片。问题在于，如果A节点宕机，集群会变成红色，需要找到避免这种情况的方法。

首先，我需要理解为什么集群当前是绿色的。因为所有的主分片和副本分片都处于正常分配状态。当A节点宕机时，A上的所有主分片都不可用了，这时候Elasticsearch应该会尝试将对应的副本分片提升为主分片。但问题可能出在副本分片的分布上。如果B节点全是副本分片，而D节点既有主又有副本，那当A宕机后，原本在A上的主分片的副本是否存在于其他节点上？

根据用户描述的情况，可能副本分片都分布在B和D节点上。比如，假设原来的主分片在A和C上，当C被移除后，主分片可能迁移到了D，或者原来的分片分配在A、B、C三个节点上。但现在C被删除，分片可能重新分配到D节点。不过用户提到现在A全是主分片，B全是副本，D有混合。这可能说明分片的分配策略存在问题，导致主分片集中在一个节点，而副本集中在另一个节点。

当A宕机时，所有的主分片丢失，这时候需要将对应的副本分片提升为主分片。但如果这些副本分片所在的节点（比如B和D）是否能够承载这些主分片？假设B节点上的副本分片足够，那应该可以接管主分片。但为什么集群会变红呢？可能的情况是，当A宕机后，某些主分片的副本分片可能不存在于其他节点，或者副本分片所在的节点无法被正确分配，导致部分分片无法恢复，从而集群变红。

需要确定当前分片分配的具体情况。比如，每个主分片的副本是否存在且位于不同的节点。例如，假设原来的每个主分片在A节点，而其副本在B节点。当删除C节点后，可能分片重新分配，但可能由于某些原因，主分片仍然集中在A，而副本分片在B。当新增了D节点后，可能部分副本分片被分配到D节点。但此时如果A宕机，所有主分片丢失，副本分片是否足够覆盖所有主分片？

比如，如果有10个主分片在A节点，每个主分片的副本分片可能在B或D节点。如果所有主分片的副本分片都存在且处于正常状态，那么当A宕机时，这些副本会被提升为主分片，集群可能变为黄色（因为副本数暂时减少），但不会变红。只有当某些分片的副本不存在时，才会变红。

但是用户说此时集群是绿色，说明所有主分片和副本分片都已分配。那为什么当A宕机会变红？可能当A宕机后，原本主分片的副本分片所在的节点（比如B和D）是否能被正确提升为主分片？或者是否存在某些分片的副本分片没有被正确分配到其他节点？

可能的问题在于，主分片全部集中在A节点，而副本分片在B和D节点。当A宕机后，所有主分片丢失，Elasticsearch会将副本分片提升为主分片。此时，新的主分片应该分布在B和D节点上。然后，集群需要为这些新的主分片创建副本。但由于只剩下B和D两个节点，而副本设置是1，可能需要将副本分配到另一个节点。如果有三个节点的话，可能没问题，但现在只有B和D两个节点的话，副本可能无法分配，因为不能在同一个节点上放置主分片和其副本。例如，如果主分片在B，副本必须到D，反之亦然。如果有足够的节点，副本可以分配，但可能当只剩下两个节点时，每个主分片的副本需要分配到另一个节点，这时可能不会有问题，但为什么用户说会变成红色？

或者，可能当A宕机后，某些主分片的副本分片也位于A节点？这不太可能，因为用户说A节点全是主分片。因此，副本应该在B和D节点。可能当A宕机后，原本的主分片在A，副本在B和D，所以每个主分片的副本是否存在？

例如，每个主分片有一个副本，所以总共有10个主分片和10个副本分片。假设主分片全在A节点，而副本分片全在B节点，那么当A宕机，副本分片会被提升为主分片，此时新的主分片在B节点，而需要为这些新的主分片创建副本。但此时剩下的节点是B和D，那么副本可以分配到D节点。然而，如果原来的副本分片全部在B节点，当A宕机后，这些副本被提升为主分片，然后新的副本分片需要分配到D节点，此时可能没问题。但用户可能的情况是，当A宕机后，副本分片可能原本并不存在于其他节点，导致主分片丢失。

这里可能存在用户描述中的另一个情况：虽然集群状态是绿色，但副本分片可能分布不均。例如，某些主分片的副本可能被分配到了同一节点，当该节点宕机时，无法找到副本。或者，当移除C节点后，分片的分配策略导致副本分片没有正确分布在不同的节点上。

可能的根本原因是主分片和副本分片没有分布在不同的节点，导致当某个节点宕机时，无法恢复。例如，主分片全在A节点，而副本分片可能在B节点，而D节点可能有一些主或副本分片。当A宕机后，副本分片在B会被提升为主分片，但由于副本数设置为1，此时每个新的主分片需要有一个副本，这时候可能无法分配到其他节点，例如如果只剩下B和D两个节点，那么每个主分片的副本可以分配到另一个节点。但可能因为D节点已经有部分分片，导致分配不均，或者某些分片的副本无法分配，导致部分分片缺失，从而集群变红。

要解决这个问题，应该确保主分片和其对应的副本分片分布在不同的节点上，避免单点故障。当前情况下，主分片全在A节点，这显然是不合理的，因为一旦A宕机，所有主分片都会丢失，此时需要依赖副本分片。但副本分片如果分布在B和D节点，应该可以被提升为主分片，前提是每个主分片的副本确实存在。

可能用户的问题在于，主分片全部集中在A节点，而副本分片可能没有覆盖所有主分片，或者在A宕机后，副本分片所在的节点不足以承载所有的主分片。

解决这个问题的办法是调整分片的分配，使得主分片和副本分片均匀分布在不同的节点上，避免所有主分片集中在同一个节点。这样，当任何一个节点宕机时，其他节点可以接管。

可能的解决方案步骤包括：

  1. 调整分片分配策略，避免主分片集中在单一节点。可以通过Elasticsearch的分片分配过滤设置或调整平衡参数来实现。

  2. 手动移动一些主分片到其他节点，或者调整副本分片的分布，确保每个主分片的副本位于不同的节点。

  3. 检查集群的分配策略，如cluster.routing.allocation参数，确保分片能够均匀分布。

具体来说，可能的问题在于Elasticsearch默认的分片分配策略可能因为节点离开或加入而导致分片分配不均。例如，当C节点被移除，D节点加入后，Elasticsearch可能没有重新平衡分片，导致主分片仍集中在A节点，副本集中在B节点，而D节点可能只分配了部分分片。

解决方法可能包括：

  • 使用Cluster Reroute API手动将部分主分片迁移到其他节点。

  • 调整分片分配设置，如cluster.routing.allocation.balance参数，确保主分片和副本分片均匀分布。

  • 确保每个主分片的副本分片位于不同的节点。例如，在三个节点的情况下，主分片和其副本分片应位于不同的节点，这样当任何一个节点宕机时，副本分片可以接管。

例如，当前的情况是A节点有所有主分片，而B节点有所有副本分片，D节点可能有部分主或副本分片。这可能是因为当C节点被删除，D节点加入后，分片的重新分配没有正确进行。可能需要重新平衡分片，使得主分片分布在A、B、D三个节点上，而每个主分片的副本分布在另外两个节点中的一个。

另一个可能性是，当集群中有三个节点时，副本分片可以分布在不同的节点，但当移除C节点并添加D节点后，可能存在分片分配的不均衡，需要触发分片的重新平衡。

可能的解决步骤：

  1. 检查当前分片的分布情况，使用_cat/shards API查看每个分片的位置。

  2. 如果发现主分片集中在A节点，可以使用Cluster Reroute API将部分主分片移动到B或D节点。但需要注意，主分片的移动需要先将其副本分片提升为主分片，这可能需要先禁用副本，或者调整设置。

或者，更好的方法是让Elasticsearch自动重新平衡分片，但可能需要调整分配策略。

  1. 调整分片分配策略，例如设置cluster.routing.allocation.total_shards_per_node参数，限制每个节点上的分片数量，避免单个节点承担过多分片。

  2. 确保副本分片被正确分配。可能需要检查索引的设置，确保每个主分片的副本分片被分配到不同的节点。例如，如果有三个节点，副本分片应该分布在不同的节点，但当前可能只有两个节点（如果D节点加入后，但可能因为某些原因副本分配不均）。

例如，假设索引的副本数设置为1，则每个主分片的副本会分配到另一个节点。当有三个节点时，每个主分片和其副本会位于不同的节点。但当前只有A、B、D三个节点，可能分配策略导致主分片集中在A，而副本在B和D。

但用户描述中当前的情况是A全是主分片，B全是副本，D有混合。这可能说明分片分配策略存在问题，导致主分片无法迁移到其他节点。

另一个可能性是，在移除C节点后，主分片可能从C迁移到了A，因为A可能是一个更合适的主节点（比如是master节点），而副本分片迁移到了B和D。但现在A承担了所有主分片，导致风险。

解决这个问题的方法之一是强制将主分片分布在多个节点上。可以通过调整分片分配策略，例如使用awareness属性，或者排除某个节点只承载副本分片，或者使用分片分配过滤器。

另一个方法是手动将部分主分片迁移到其他节点。例如，将部分主分片从A节点迁移到B或D节点，但需要注意Elasticsearch不允许直接移动主分片，必须通过让副本分片提升为主分片的方式。这可能需要临时增加副本数量，进行重新平衡，然后再调整回来。

可能的步骤：

  1. 临时将索引的副本数增加到2，这样每个主分片会有两个副本分片。这样可以确保有足够的分片副本分布在不同的节点。但这样会增加分片总数，需要确保节点有足够资源。

  2. 等待分片重新分配完成，此时每个主分片会有两个副本分布在B、D或其他节点。

  3. 然后减少副本数回到1，这可能触发分片的重新分配，但需要确保在减少副本时，分片均匀分布。

或者，更直接的方法是调整分片分配策略，例如设置：

cluster.routing.allocation.balance.primary: 0.5

cluster.routing.allability.balance.shard: 0.5

这些参数可以调整主分片和副本分片的平衡，使得主分片更均匀地分布在各个节点。

另外，可以设置：

cluster.routing.allocation.total_shards_per_node: 7 （因为总共有20个分片，3个节点的话每个节点大约7个）

这可以限制每个节点上的分片数量，防止某个节点承担过多分片。

另外，可能需要排除A节点作为主分片的候选节点，强制主分片分配到其他节点。例如：

1
2
3
4
5
6
PUT _cluster/settings
{
    "transient" : {
        "cluster.routing.allocation.exclude._name" : "A"
    }
}

这会禁止新的分片分配到A节点，但已有的分片可能需要手动移动。不过这可能不是一个好方法，因为这可能导致数据移动压力。

更合理的做法是让Elasticsearch自动平衡分片。可能当前自动平衡没有被触发，或者存在分配规则限制。

另外，检查是否启用了分片重新平衡。例如，cluster.routing.rebalance.enable 是否设置为all（默认）。如果设置为none，则分片不会自动重新平衡。

此外，当节点D加入集群后，Elasticsearch会自动将分片移动到新节点以实现平衡，但可能由于其他设置导致没有进行。比如，cluster.routing.allocation.enable设置是否是all（默认允许分配）。

综上，解决方案应该是调整分片分配策略，确保主分片和副本分片均匀分布在所有节点，避免单点故障。可以通过以下步骤：

  1. 检查当前分片分配情况，确认是否存在某些节点承担过多主分片。

  2. 调整分片分配策略，例如设置cluster.routing.allocation.balance参数，或设置total_shards_per_node限制每个节点的分片数。

  3. 手动触发分片重新平衡，或者等待Elasticsearch自动进行。

  4. 确保每个主分片的副本位于不同的节点，这样当某个节点宕机时，副本可以接管。

具体到用户的情况，可能当前A节点拥有所有主分片，这违反了分片分配的最佳实践。需要将部分主分片迁移到其他节点。但由于Elasticsearch不允许直接移动主分片，可能需要通过增加副本数量，然后减少，或者排除A节点作为主分片的候选节点，触发主分片的迁移。

例如，可以临时将索引的副本数设置为0，这将删除所有副本分片，此时主分片仍然在A节点。然后再将副本数设置为1，这将创建新的副本分片，此时Elasticsearch会将主分片和副本分片分配到不同的节点，可能分布在B和D节点上。不过这可能存在数据丢失的风险，需要谨慎操作。

或者，使用Cluster Reroute API手动迁移分片。例如，将某些主分片的副本分片提升为主分片，然后重新分配。但这个过程比较复杂，需要确保操作正确。

另一种方法是排除A节点，使其不承载任何分片，迫使Elasticsearch将分片迁移到其他节点。例如：

1
2
3
4
5
6
7
PUT _cluster/settings
{

    "transient": {
        "cluster.routing.allocation.exclude._name": "A"
    }
}

然后等待分片从A迁移到其他节点。完成后再将A节点重新加入集群，并调整分配设置。这可能是一个更直接的方法，但需要确保集群有足够的资源来移动分片。

总结，解决这个问题的关键点在于重新平衡分片，使得主分片和副本分片均匀分布在各个节点，避免单点故障。特别是不能让所有主分片集中在同一个节点。通过调整分片分配策略或手动迁移分片，可以避免当A节点宕机时集群变红的情况。

回答

为了确保Elasticsearch集群在节点A宕机时仍保持可用，需重新平衡分片分布，避免主分片集中在单一节点。以下是具体步骤：

1. 调整分片分配策略

  • 限制单节点的主分片数量：通过设置total_shards_per_node，强制分片均匀分布。

    1
    2
    3
    4
    5
    6
    PUT _cluster/settings
    {
      "transient": {
        "cluster.routing.allocation.total_shards_per_node": 7
      }
    }

    这将限制每个节点最多承载7个分片（总共有20个分片，3个节点）。

  • 优化主副分片平衡：调整权重参数，确保主分片均匀分布。

    1
    2
    3
    4
    5
    6
    7
    PUT _cluster/settings
    {
      "transient": {
        "cluster.routing.allocation.balance.primary": 0.5,
        "cluster.routing.allocation.balance.shard": 0.5
      }
    }

2. 强制分片重新平衡

  • 排除节点A以迁移分片：

    1
    2
    3
    4
    5
    6
    PUT _cluster/settings
    {
      "transient": {
        "cluster.routing.allocation.exclude._name": "A"
      }
    }

    此操作会将A节点上的分片迁移到B和D节点。等待集群状态变绿后，撤销排除设置：

    1
    2
    3
    4
    5
    6
    PUT _cluster/settings
    {
      "transient": {
        "cluster.routing.allocation.exclude._name": null
      }
    }

3. 手动调整分片分布（可选）

若自动平衡不理想，使用Cluster Reroute API手动迁移分片：

1
2
3
4
5
6
7
8
9
10
11
12
13
POST _cluster/reroute
{
  "commands": [
    {
      "move": {
        "index": "your_index", 
        "shard": 0,
        "from_node": "A",
        "to_node": "B"
      }
    }
  ]
}

注意：直接移动主分片需谨慎，建议优先依赖自动平衡。

4. 验证分片分布

使用以下命令检查分片分布：

1
GET _cat/shards/your_index?v

确保主分片和副本分布在所有节点上，且没有单节点承担所有主分片。

5. 预防未来单点故障

  • 增加副本数量：若资源允许，将副本数设为2，增强冗余。

    1
    2
    3
    4
    PUT your_index/_settings
    {
      "index.number_of_replicas": 2
    }

  • 定期监控分片分布：使用Elasticsearch监控工具（如Kibana）持续观察分片平衡状态。

总结

通过强制分片重新分配并调整集群设置，确保主分片和副本分片均匀分布在所有节点，从而避免单点故障导致集群不可用。优先依赖Elasticsearch的自动平衡机制，必要时辅以手动调整。

问：我确认了一下，A上面的所有主分片，在B和D上都有副本分片，这时候A宕机后，集群是否仍能正常运行，集群是绿色的还是红色的？B和D上的副本分片会自动升级成主分片吗？如果不升级为主分片，用户搜索数据时他们能用上吗？

问题分析

  • A节点：承载所有主分片。
  • B和D节点：承载所有副本分片。
  • A宕机后：B和D节点上的副本分片是否会自动升级为主分片？集群状态如何？用户能否正常搜索数据？

1. A宕机后集群的状态

  • 集群状态：如果A宕机，B和D节点上的副本分片会自动升级为主分片，集群状态仍为绿色。
  • 原因：Elasticsearch会自动将副本分片提升为主分片，确保数据可用性和集群健康。

2. 副本分片升级为主分片

  • 自动升级：A宕机后，B和D节点上的副本分片会立即升级为主分片。
  • 触发条件：主分片不可用时，副本分片会自动接管。
  • 升级过程：
    1. Elasticsearch检测到A节点不可用。
    2. 将B和D节点上的副本分片提升为主分片。
    3. 集群重新平衡，确保每个分片都有主分片和副本分片。

3. 用户搜索数据的影响

  • 数据可用性：用户仍能正常搜索数据。
  • 原因：
    • 副本分片升级为主分片后，数据完整性和一致性得以保留。
    • 搜索请求会路由到新的主分片（原副本分片）。
  • 性能影响：
    • 如果A节点承载了大量查询负载，B和D节点可能需要分担更多负载，可能导致查询性能略有下降。
    • 如果集群资源充足，性能影响可以忽略。

4. 集群恢复

  • A节点恢复后：
    • A节点重新加入集群。
    • Elasticsearch会重新分配分片，确保主分片和副本分片均匀分布。
    • A节点上的分片会重新同步数据，恢复为副本分片或主分片。

5. 如何避免类似问题

  • 均匀分布主分片：通过调整分片分配策略，确保主分片均匀分布在所有节点。

    1
    2
    3
    4
    5
    6
    7
    PUT _cluster/settings
    {
      "transient": {
        "cluster.routing.allocation.balance.primary": 0.5,
        "cluster.routing.allocation.balance.shard": 0.5
      }
    }

  • 增加副本数量：如果资源允许，增加副本数（如number_of_replicas: 2），进一步增强冗余。

    1
    2
    3
    4
    PUT your_index/_settings
    {
      "index.number_of_replicas": 2
    }

  • 定期监控分片分布：使用_cat/shards API检查分片分布，确保没有单点故障风险。

    1
    GET _cat/shards/your_index?v

总结

  • A宕机后：集群状态仍为绿色，B和D节点上的副本分片会自动升级为主分片。
  • 用户搜索：数据可用性不受影响，用户仍能正常搜索。
  • 建议：通过优化分片分配策略和增加副本数量，避免单点故障风险。

服务器重启了，如何用journalctl查看重启的原因

使用journalctl命令可以查看Linux服务器重启的原因具体方法如下：

使用journalctl --list-boots查看启动记录
该命令会列出系统的所有启动记录，包括每次启动和停止（关机或重启）的时间。这可以帮助你确定服务器重启的大致时间范围 。

使用journalctl -b -1查看上一次启动的日志
该命令会显示上一次系统启动时的日志信息，包括可能导致重启的原因。-b选项表示“boot”，而-1表示上一次启动。如果服务器多次重启，你可以通过调整数字（如-2、-3等）来查看更早的启动日志。

结合其他日志信息
虽然journalctl提供了丰富的系统日志信息，但有时候结合其他日志文件（如/var/log/messages、/var/log/syslog、/var/log/dmesg等）中的信息可能更有助于确定重启的具体原因。这些日志文件可能会记录与重启相关的硬件问题、服务异常或系统错误等信息。

我是如何从零开始手搓一个独立游戏并上架 Steam 的
https://www.v2ex.com/t/1102126

I am rich and have no idea what to do (vinay.sh)
https://news.ycombinator.com/item?id=42579873

一个AI相册搜索应用的两年
https://mazzzystar.com/2024/07/21/Two-Years-of-an-AI-Photo-Album-Search-App-zh/
https://v2ex.com/t/955496

“袋鼠书”作者Jay Alammar深度解析DeepSeek-R1核心技术
https://mp.weixin.qq.com/s/76eI7hJxS0qGX0j-9ABflw

深度学习论文精读
https://github.com/mli/paper-reading

https://www.streamlinehq.com/illustrations/free-illustrations-bundle?search=moon 插画
https://www.freepik.com/free-vector/colorful-memphis-design-background-vector_3893585.htm 免费文生图

3000 Daily Use Sentences in English
https://spokenenglishtips.com/3000-daily-use-sentences-in-english/

1000+ Common Daily English Phrases for Beginners (PDF)
https://www.learnenglishteam.com/common-daily-english-phrases-for-beginners/#google_vignette

English Story Books for Intermediate Learners (PDF Level 2 & 3)
https://www.learnenglishteam.com/free-english-story-books-level-2-3/

https://tatoeba.org/zh-cn/audio/index/eng

Download English Listening Lessons
https://adeptenglish.com/downloads/listening/

https://listeninenglish.com/aef-d12.php
https://adeptenglish.com/

词典
https://github.com/kajweb/dict

Nginx 反爬策略，只允许谷歌爬虫

问题：

  • 网站的一些页面总是被刷，服务器的 CPU 和 DB 连接数都很高，影响正常用户使用
  • 想针对这些页面设置一些规则，只允许谷歌的爬虫爬取，其它爬虫都返回 429
    • 这些页面只是用来做 SEO 用，真实用户不会访问，所以不需要区分真实用户 IP
  • 网站使用 nginx 服务器，nginx 前面有 LB 负载均衡，LB 前面有 CloudFlare CDN。
    • 所以客户端真实 IP 要从 x-forward-for 头中取，并且只信任特定的代理 IP。
    • LB 不会加到 x-forward-for 头，CloudFlare 会。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Trust Lan proxy ip range, such as LB ip
set_real_ip_from 10.0.0.0/8;
set_real_ip_from 172.16.0.0/12;
set_real_ip_from 192.168.0.0/16;

# Trust CloudFlare proxy ip range: https://www.cloudflare.com/zh-cn/ips/
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
...

# Read X-Forwarded-For, recursively get the leftmost real IP to make geo module works
real_ip_header X-Forwarded-For;
real_ip_recursive on;

# Google IP range: https://www.gstatic.com/ipranges/goog.json
geo $is_google {
    default 0;
    8.8.4.0/24 1;
    8.8.8.0/24 1;
    8.34.208.0/20 1;
    ...
}

server {
    location ~ ^/google-test$ {
        if ($is_google = 0) { # return 429 if the request comes from Google 
            default_type text/plain;
            return 429 "429 Client IP: $remote_addr\nX-Forwarded-For: $http_x_forwarded_for\nReal IP Header: $realip_remote_addr\n";
        }
        
        # otherwise, run origin rule 
        try_files $uri $uri/ /index.php?$query_string;
    }
}

港股打新专业名词大全
https://zhuanlan.zhihu.com/p/365424171

  • 甲组
  • 甲尾
  • 乙组
  • 乙头
  • 顶头槌
  • 国际配售
  • 公开配售
  • 绿鞋
  • 保荐人
  • 基石投资人
  • 暗盘
  • 申购
  • 一手融
  • 融资申购
  • 现金申购
  • 中签
  • 回拨
  • 超购倍数
  • 孖展
  • 一手中签率
  • 入金
  • 出金
  • 转仓
  • 入场费
  • 冻结资金
  • 修改/撤销

AI 外教提示词

Prompt:

"You are an intelligent English language learning assistant powered by GPT-4o-audio-preview, designed to help Chinese students improve their pronunciation and intonation. Your role is to act as a friendly, patient English teacher who understands that students may mix Chinese and English in their speech. The student is at an intermediate level, eager to practice speaking but struggles with pronunciation accuracy and natural intonation. You are familiar with how English is taught in China and can respond like a local teacher.

Here’s how you should behave:

  1. Start the session: Greet the student warmly in English, introduce yourself as their speaking coach, and invite them to say a simple sentence (e.g., ‘Hello, how are you today?’) to begin. Add a friendly note in Chinese, like ‘别紧张，我们一起来练习！’ (Don’t be nervous, let’s practice together!).

  2. Handle mixed input: Listen to the student’s audio input, which may include both English and Chinese (e.g., ‘apple 这个词是什么意思?’ or ‘我想问这个苹果多少钱应该用英文怎么说?’). Recognize and respond to Chinese questions naturally, providing answers in English with Chinese clarification if needed.

    • Example: If the student says ‘apple 这个词是什么意思?’, respond with: ‘Good question! “Apple” means 苹果 in Chinese. It’s a fruit. Try saying “apple” after me—listen: “AP-ple”.’

    • Example: If the student says ‘我想问这个苹果多少钱应该用英文怎么说?’, respond with: ‘You want to ask about the price? In English, you can say: “How much is this apple?” Listen to me: “How MUCH is this AP-ple?” Now you try!’

  3. Analyze pronunciation and intonation: For any English the student speaks, analyze their pronunciation (sounds, word stress) and intonation (rising/falling tones, rhythm) compared to standard American or British English. Point out specific errors (e.g., ‘Your “th” in “this” sounds like “dis”—let’s fix that!’) and praise successes (e.g., ‘Nice rising tone on the question!’).

  4. Demonstrate: Use your audio output to model correct pronunciation and intonation. For example, say, ‘Listen to me: “How much is this apple?”—notice the stress on “much”. Try it again!’

  5. Encourage practice: Prompt the student to repeat or try new sentences. Suggest interactive exercises like a mini-conversation (e.g., ‘Let’s pretend we’re at a market. Ask me about the apple’s price!’) or a repeat-after-me game.

  6. Adapt to the student: If they struggle with English, simplify the task or focus on one skill (e.g., just the ‘th’ sound). If they mix in Chinese, answer their question and guide them back to English practice. For advanced students, challenge them with longer sentences.

  7. Keep it engaging: Use a warm, upbeat tone. Add encouragement in English and occasional Chinese (e.g., ‘很好，你进步很快!’—Very good, you’re improving fast!) to build confidence.

The session should feel like a natural, supportive conversation. Respond to both English and Chinese input, always steering the focus back to English practice. Use your audio capabilities to emphasize correct sounds and rhythms. Begin now by greeting the student and starting the practice."

审计

sudo apt-get install auditd
sudo systemctl enable --now auditd
/etc/audit/rules.d/audit.rules
    -a always,exit -F path=/usr/bin/php8.3 -F perm=x -F auid>=1000 -F auid!=4294967295 -k php-start

sudo augenrules --load
sudo systemctl restart auditd
sudo ausearch -ts yesterday  -k php-start
sudo ausearch -ts yesterday  -k php-start -p 1331786

机器学习，王天一，

  • 03 数理统计
  • 07 机器学习概论

整体来说，测试误差与模型复杂度之间呈现的是抛物线的关系。当模型复杂度较低时，测试误差较高；随着模型复杂度的增加，测试误差将逐渐下降并达到最小值；之后当模型复杂度继续上升时，测试误差会随之增加，对应着过拟合的发生。

在模型选择中，为了对测试误差做出更加精确的估计，一种广泛使用的方法是交叉验证。交叉验证思想在于重复利用有限的训练样本，通过将数据切分成若干子集，让不同的子集分别组成训练集与测试集，并在此基础上反复进行训练、测试和模型选择，达到最优效果。

泛化误差的构成可以分为三部分：偏差（bias）、方差（variance）和噪声（noise）。

  • 偏差表示算法预测值和真实结果之间的偏离程度，刻画的是模型的欠拟合特性；
  • 方差表示数据的扰动对预测性能的影响，刻画的是模型的过拟合特性；
  • 噪声表示在当前学习任务上能够达到的最小泛化误差，刻画的是任务本身的难度。
  • 对任何实际的模型来说，偏差和方差都难以实现同时优化，反映出欠拟合与过拟合之间难以调和的矛盾。

clickhouse group 优化

CREATE TABLE top_xxx
ENGINE = Log
AS SELECT
    xxx,
    count(*) AS count
FROM all_xxx
GROUP BY xxx 
HAVING count(*) > 100

默认对大数据 group 会爆内存，有几种优化方式

SET max_bytes_before_external_group_by = 10000000000;

0 rows in set. Elapsed: 204.055 sec. Processed 1.52 billion rows, 57.04 GB (7.46 million rows/s., 279.53 MB/s.)
Peak memory usage: 9.35 GiB.

SET optimize_aggregation_in_order = 1

0 rows in set. Elapsed: 52.472 sec. Processed 1.26 billion rows, 40.17 GB (23.94 million rows/s., 765.60 MB/s.)
Peak memory usage: 446.70 MiB.


CREATE table test_SummingMergeTree
(
    `xxx` String,
    `count` Int32
)
ENGINE = SummingMergeTree()
order by xxx;

insert into test_SummingMergeTree select xxx, 1 from all_xxx;

0 rows in set. Elapsed: 138.208 sec. Processed 1.26 billion rows, 40.17 GB (9.09 million rows/s., 290.67 MB/s.)
Peak memory usage: 180.39 MiB.

select xxx,sum(count) from test_SummingMergeTree group by xxx order by sum(count) desc limit 10;

10 rows in set. Elapsed: 68.933 sec. Processed 487.98 million rows, 28.57 GB (7.08 million rows/s., 414.43 MB/s.)
Peak memory usage: 9.50 GiB.

OPTIMIZE TABLE test_SummingMergeTree FINAL;
0 rows in set. Elapsed: 59.432 sec.

select * from test_SummingMergeTree order by count desc limit 10;
10 rows in set. Elapsed: 2.611 sec. Processed 232.72 million rows, 12.35 GB (89.14 million rows/s., 4.73 GB/s.)
Peak memory usage: 32.06 MiB.