PAT--L3-001. 凑零钱

该博客介绍了一道编程题目,题号为PAT L3-001,内容涉及在火星商店购物时使用不同星球硬币支付且不找零的场景。博主讨论如何帮助韩梅梅通过排序硬币面值并使用深度优先搜索(DFS)策略来确定是否能精确凑出所需付款金额。题目提供输入输出样例,并指出当解不唯一时应输出最小序列。若无法凑出金额,则输出"No Solution”。

题目链接:https://www.patest.cn/contests/gplt/L3-001

题目描述:

韩梅梅喜欢满宇宙到处逛街。现在她逛到了一家火星店里,发现这家店有个特别的规矩:你可以用任何星球的硬币付钱,但是绝不找零,当然也不能欠债。韩梅梅手边有104枚来自各个星球的硬币,需要请你帮她盘算一下,是否可能精确凑出要付的款额。

输入格式:

输入第一行给出两个正整数:N(<=104)是硬币的总个数,M(<=102)是韩梅梅要付的款额。第二行给出N枚硬币的正整数面值。数字间以空格分隔。

输出格式:

在一行中输出硬币的面值 V1 <= V2 <= … <= Vk,满足条件 V1 + V2 + … + Vk = M。数字间以1个空格分隔,行首尾不得有多余空格。若解不唯一,则输出最小序列。若无解,则输出“No Solution”。

注:我们说序列{A[1], A[2], …}比{B[1], B[2], …}“小”,是指存在 k >= 1 使得 A[i]=B[i] 对所有 i < k 成立,并且 A[k] < B[k]。

输入样例1:
8 9
5 9 8 7 2 3 4 1
输出样例1:
1 3 5
输入样例2:
4 8
7 2 4 3
输出样例2:
No Solution

因为题目要求输出最小序列,所以我们可以先按面值小到大的顺序将硬币排序,之后就是 DFS 了,每一个硬币要么选要么不选,这两种情况分情况处理

#include<cstdio>
[root@localhost work]# sudo find / -xdev -type f -size +100M -exec ls -lh {} \; -rw-r--r--. 1 root root 101M Feb 28 2025 /var/lib/rpm/Packages -rw-r--r--. 1 root root 156M Jun 22 2024 /var/cache/yum/x86_64/7/updates/gen/primary_db.sqlite -rw-r--r--. 1 root root 149M Jun 22 2024 /var/cache/yum/x86_64/7/updates/gen/filelists_db.sqlite -rw-r--r--. 1 root root 117M Jun 21 2024 /var/cache/yum/x86_64/7/updates/packages/firefox-115.12.0-1.el7.centos.x86_64.rpm -rw-r--r--. 1 root root 1.1G Oct 4 23:45 /tmp/spring.log.2025-10-04.128181976214538690.tmp -rw-r--r--. 1 root root 1.7G Oct 5 15:00 /tmp/spring.log.2025-10-04.228213919973839816.tmp -rw-r--r--. 1 root root 2.3G Oct 10 23:45 /tmp/spring.log.2025-10-10.028656801304903358.tmp -rw-r--r--. 1 root root 2.7G Oct 11 23:45 /tmp/spring.log.2025-10-10.228732319985996298.tmp -rw-r--r--. 1 root root 1.5G Oct 4 15:03 /tmp/spring.log.2025-10-04.028138434113501828.tmp -rw-r--r--. 1 root root 1.4G Oct 12 15:03 /tmp/spring.log.2025-10-12.028829562166827530.tmp -rw-r--r--. 1 root root 722M Oct 9 23:45 /tmp/spring.log.2025-10-09.028624370054257272.tmp -rw-r--r--. 1 root root 681M Oct 7 23:45 /tmp/spring.log.2025-10-07.228451583042218185.tmp -rw-r--r--. 1 root root 1.1G Oct 12 23:45 /tmp/spring.log.2025-10-12.128873138133991399.tmp -rw-r--r--. 1 root root 1.1G Oct 5 23:45 /tmp/spring.log.2025-10-05.028268051194354719.tmp -rw-r--r--. 1 root root 2.8G Oct 3 23:45 /tmp/spring.log.2025-10-03.028041361425305587.tmp -rw-r--r--. 1 root root 2.7G Oct 8 23:45 /tmp/spring.log.2025-10-07.328473120035804793.tmp -rw-r--r--. 1 root root 1.7G Oct 13 15:02 /tmp/spring.log.2025-10-12.228905120362616249.tmp -rw-r--r--. 1 root root 360M Oct 13 16:04 /tmp/spring.log.2025-10-13.028959350972534024.tmp -rw-r--r--. 1 root root 739M Oct 13 23:45 /tmp/spring.log.2025-10-13.128970115527045867.tmp -rw-r--r--. 1 root root 674M Oct 14 06:53 /tmp/spring.log.2025-10-14.029002515536531512.tmp -rw-r--r--. 1 root root 102M Nov 12 2024 /usr/lib/locale/locale-archive -rw-r--r--. 1 root root 208M Sep 23 10:25 /opt/nubosh/vmsec-host/pat/av/qowl.tgz 执行结果
最新发布
10-15
<think>我们有一个命令:`sudo find / -xdev -type f -size +100M -exec ls -lh {} \;`,这个命令的作用是查找根目录`/`下(不跨越文件系统)所有大于100MB的普通文件,并显示它们的详细信息(包括文件大小、路径等)。由于`-xdev`选项确保不会查找其他挂载点(比如`/boot`, `/home`等),所以结果只包含挂载在根目录的文件系统中的大文件。 当我们发现`/dev/mapper/centos-root`磁盘使用率达到100%时,通过这个命令我们可以找出哪些大文件占用了大量空间,从而定位问题。 ### 分析步骤 1. **理解命令输出格式**: 命令输出类似于: ``` -rw------- 1 root root 2.3G Mar 31 10:00 /var/log/syslog.1 -rw-r--r-- 1 root root 1.5G Apr 1 09:00 /opt/large_file.dat ``` 每行显示一个文件的权限、链接数、所有者、所属组、大小、最后修改时间和路径。 2. **关注文件路径**: 重点查看文件路径,特别是位于以下常见目录的大文件: - `/var/log`:系统日志文件,容易堆积 - `/var/cache`:应用程序缓存 - `/opt`:第三方软件安装目录 - `/tmp`:临时文件(但注意这里可能挂载了tmpfs) - `/usr`:系统应用程序 - `/home`:用户文件(但注意如果/home是独立分区则不会出现在这里,因为使用了`-xdev`) 3. **常见原因分析**: - **日志文件过大**:如`/var/log`下的系统日志或应用日志(如`syslog`, `messages`, `secure`, `nginx/access.log`等)可能未轮转清理。 - **缓存文件**:某些应用程序(如`yum/dnf`缓存、Docker镜像、浏览器缓存)可能占用大量空间。 - **临时文件**:例如未清理的安装文件或下载文件。 - **应用数据**:如数据库文件(如果数据库在根目录下)、应用产生的数据文件等。 - **Core dump文件**:程序崩溃生成的core文件可能很大。 4. **具体分析示例**: 假设我们得到以下输出: ``` -rw------- 1 root root 8.0G Apr 10 12:00 /var/lib/docker/containers/.../...-json.log -rw-r--r-- 1 root root 1.2G Mar 15 08:00 /var/cache/yum/x86_64/7/update/packages/somepackage.rpm -rw-r--r-- 1 root root 3.5G Apr 10 10:00 /home/user/video.mp4 ``` 分析: - 第一条:Docker容器日志文件占用了8GB,这是常见问题,需要清理或配置日志轮转。 - 第二条:Yum缓存文件,可以通过`yum clean all`清理。 - 第三条:用户目录下的视频文件,但注意如果`/home`是独立分区,则不会出现在根分区查找结果中(因为`-xdev`)。但这里出现说明`/home`没有独立分区,是根分区的一部分。 5. **处理建议**: - **日志文件**:使用`logrotate`配置日志轮转,或手动清理(使用`truncate`或`rm`,注意如果服务正在写日志,可能需要重启服务)。 - **缓存文件**:使用相应的清理命令(如`yum clean all`, `dnf clean all`)。 - **临时文件**:检查`/tmp`和`/var/tmp`,删除不需要的文件。 - **应用数据**:检查是否有不需要的大文件,进行归档或删除。 - **注意**:删除文件后,如果文件正在被进程打开,空间不会立即释放,需要重启进程或重启应用。可以使用`lsof | grep deleted`查看被删除但仍被进程占用的文件。 6. **其他可能**: 如果没有找到很多大文件,但磁盘仍然显示,可能是大量小文件占用(此时`du`命令更有效)或者是文件系统元数据占用(如inode用尽)。我们可以通过以下命令检查: ```bash # 检查inode使用情况 df -i / # 使用du命令查看各目录占用 du -sh /* 2>/dev/null | sort -h ``` ### 总结 通过分析`sudo find / -xdev -type f -size +100M -exec ls -lh {} \;`的输出,我们可以快速定位根分区下的大文件,从而有针对性地进行清理或迁移,解决磁盘的问题。同时,定期清理和日志轮转是预防此类问题的有效方法[^3]。 --- §§相关问题§§ 1. Linux 系统中有哪些常见的日志文件需要定期清理? 2. 如何配置 `logrotate` 来实现日志文件的自动轮转和清理? 3. 如何安全地清理被进程占用但已被删除的大文件? 4. 除了查找大文件,还有哪些方法可以排查磁盘空间不足的问题? </think>根据命令 `sudo find / -xdev -type f -size +100M -exec ls -lh {} \;` 的执行结果分析磁盘空间占原因,以下是系统性的排查流程和关键判断点: --- ### **分析步骤与诊断逻辑** #### 1. **解析命令输出格式** 命令输出格式示例: ```bash -rw------- 1 root root 15G Apr 10 09:00 /var/lib/docker/containers/.../*-json.log -rw-r--r-- 1 root root 8.2G Mar 28 14:30 /opt/app_data/large_dump.sql ``` - **关键字段**: - 文件大小(如 `15G`) - 文件路径(如 `/var/lib/docker/...`) - 最后修改时间 #### 2. **定位高嫌疑目录** 优先检查以下常见空间占用源: | **目录** | **典型大文件类型** | **潜在问题** | |------------------|----------------------------------|----------------------------------| | `/var/log` | `*.log`, `*.gz`, `journal/*` | 未轮转的日志文件[^3] | | `/var/lib/docker`| `containers/*-json.log`, `images`| Docker容器日志/镜像堆积 | | `/opt` 或 `/usr` | 应用数据文件、安装包缓存 | 未清理的临时文件或缓存 | | `/tmp` | 超大临时文件 | 未自动清理的进程残留文件 | | `/home` | 用户文件(视频/备份等) | 用户数据侵占系统空间 | #### 3. **关键诊断依据** - **日志文件过大**: - 若出现 `/var/log/messages-20230410.gz (5.8G)` → 需配置 `logrotate` - 若出现 `/var/lib/docker/*-json.log (10G+)` → Docker日志驱动需限制大小 - **应用数据堆积**: - 如 `/opt/mysql/dump.sql (12G)` → 需清理过期备份 - **异常大文件**: - 如 `/tmp/core.nginx (7.5G)` → Core dump文件需排查进程崩溃原因 #### 4. **空间释放可行性评估** | **文件类型** | **安全操作** | **风险** | |--------------------|----------------------------------|----------------------------------| | 日志文件(*.log) | 清空或轮转(`> file.log`) | 确保进程不需写入 | | 压缩文件(*.gz) | 直接删除 | 确认非关键日志 | | 应用缓存文件 | 用官方工具清理(如 `yum clean`) | 避免误删依赖文件 | | 用户数据文件 | 联系用户确认后迁移或删除 | 需权限协调 | --- ### **案例分析** 假设命令输出包含: ```bash -rw-r--r-- 1 root root 13G Apr 11 10:00 /var/log/nginx/access.log -rw------- 1 mysql mysql 9.2G Mar 30 08:00 /var/lib/mysql/ibdata1 ``` **诊断结论**: 1. Nginx 访问日志未轮转,占用 13GB(需立即压缩或清理) 2. MySQL 数据文件异常增大(需检查是否开启 `innodb_file_per_table`) --- ### **处理建议** 1. **立即清理**: ```bash # 清空日志文件(保留进程句柄) sudo truncate -s 0 /var/log/nginx/access.log # 删除旧日志 sudo find /var/log -name "*.gz" -mtime +30 -delete ``` 2. **预防措施**: - 配置日志轮转:编辑 `/etc/logrotate.d/nginx` ``` /var/log/nginx/*.log { daily rotate 7 compress missingok } ``` - 限制 Docker 日志:`docker run --log-opt max-size=100m ...` --- ### **引用验证** - 引用[^3]中 `du -h --max-depth=1` 显示 `/var` 占 4.5GB,印证日志/缓存目录是常见空间占用源 - 引用[^1]和[^2]提供了扩容方案,但需优先清理无效文件释放空间 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值