问题背景与现象安装OMS失败。原因分析查看gaussDB安装日志“/var/log/gaussdbinstall.log”。操作系统shared_buffers参数的值大于kernel.shmmax。解决办法编辑“/etc/sysctl.conf”文件，设置“kernel.shmmax”的值，格式如下。kernel.shmmax = value建议将shmmax的值设置为物理内存大小的一半。可用如下命令查看本机的物理内存：grep MemTotal /proc/meminfo显示类似如下的信息：MeMTotal: 6088240 kB则kernel.shmmax的大小可设置为6088240*1024/2=3117178880。kernel.shmmax = 3117178880执行如下命令，使SUSE Linux启动时自动读取内核参数。/sbin/chkconfig boot.sysctl on执行如下命令使内核参数生效。/sbin/sysctl -p 

GaussDB Kernel ODBC 问题定位指南1         基础知识一个典型的用户应用程序如下： 用户的应用程序，调用的ODBC的API，其实是由驱动管理器提供的，这个驱动管理器在微软上就是odbcad32(.exe/.dll)，在Linux上就是UnixODBC。再由它们来调用ODBC的具体驱动（Gauss、Oracle、TD……）。所以一般问题基本会出在以下几个方面：·         应用加载驱动管理器·         驱动管理器加载驱动·         驱动连接数据库2         问题处理2.1        应用程序加载驱动管理器2.1.1        WindowsWindows由于操作系统实现机制的问题，ODBC属于操作系统组件的一部分，除非操作系统损坏，一般不会出现应用程序加载驱动管理器失败；只会出现驱动管理器加载驱动失败。所以这里不再赘述。2.1.2        LinuxLinux上应用程序加载驱动管理器，是指的应用程序依赖于UnixODBC的相关动态库，启动时要将其加载到自己的进程空间中。加载出现问题多表现为在启动时找不到libodbc.so.x/libodbcinst.so.x等库。解决此问题：1.       首先确认环境中是否安装了UnixODBC。如果安装了，那么至少会有isql/odbcinst等工具可用。例如可使用which isql这样的命令来确定安装路径。相关的lib库一般会在which isql指定的bin目录的同级目录下，将其添加到LD_LIBRARY_PATH中重启应用程序便可。export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH特别注意，此语句只影响当前shell会话中的后续命令，其他会话不受影响，特别是后台启动的进程。如果是后台进程，请与应用程序的开发人员确认其运行环境如果修正。2.       如果确认LD_LIBRARY_PATH已经生效（可以打开/proc/应用程序pid/environ文件确认）,依然无法加载libodbc.so.x/libodbcinst.so.x，那么可能是.1或者.2的库的问题。历史原因，一般的开发环境中，UnixODBC提供的库既可能叫libodbc.so.1也可能叫libodbc.so.2。用户程序可能依赖了.2，但是环境中只有.1；也有可能是存在.2，但是依赖了.1。解决此问题，只需要在UnixODBC的lib目录下，将不存在的版本建立成软链接，保证.1与.2都存在，这样出问题的机率便会小很多。特别注意，这里强烈建议是建立软链接，而不要拷贝物理文件，不然可能出现一个应用程序进程中，加载了两个导出函数完全相同的.so，这样可能会引起一些比较难定位的启动错误，后文中会讲到。2.2        驱动管理器加载驱动 2.2.1        Windows最常见x86与x64架构不同，导致的加载失败；此问题的典型报错为：在指定的 DSN 中，驱动程序和应用程序之间的体系结构不匹配此问题可能的原因：在64位程序中使用了32位驱动，或者相反。在64位系统上：·         C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。·         C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。使用不同架构的应用程序时，请使用不同的驱动管理器；同时安装不同的驱动类型。32位系统上只能跑32位程序，也无法安装64位驱动，所以基本不用区分。如果是64位系统，那么它既支持32位程序，也支持64位程序；如果不能确定应用程序是32还是64，可以使用以下办法：1.       ctrl + shift + esc 打开任务管理器2.       查看进程列表中某进程后边有没有*32的字样（有就是32位，没有就是64位），如下图：2.2.2        Linux2.2.2.1       环境中缺少psqlodbcw.so的库一般这个问题的报错是[UnixODBC][Driver Manager]Can't open lib 'xxx/xxx/psqlodbcw.so' : file not found.可能的原因有：1.       odbcinst.ini中配置的路径不正确，最简单的办法是  ls -l 一下这个报错的文件，看看这个是不是真的存在，同时具有执行权限。2.       依赖的库不存在，此时最简单的办法是ldd 一下这个报错的文件，看看是不是真的缺少库，如果缺少库会出现如下问题：要处理这个问题，需要将unixodbc的安装目录下的lib，添加到LD_LIBRARY_PATH里，例如：export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH同时，在UnixODBC的安装的lib目录下，看看libodbcinst.so.x后边的后缀是.1还是.2。如果是.2，那么请建立一个软链接，链接到.1，便可以解决此问题。如果该目录下只有.1的库，没有.2的库，也建议建立一个.2的软链接，防止应用程序依赖于.2，我们依赖于.1，引起冲突。特别注意，当前会话的LD_LIBRARY_PATH不代表应用程序运行时也是同样的LD_LIBRARY_PATH，必要的时候，与应用程序开发人员对齐。如果是常驻进程，可以通过如下方法获取到当前进程的环境变量：cd /proc/应用程序PIDcat environ打印出来的结果可能比较乱，耐心看一下；如果内容有误，与应用程序开发人员对齐修改方法。2.2.2.2       既有.2又有.1的库，导致重复加载这种勤快的用户比较少见，但是一旦出现，很难定位，典型的报错信息是：Driver's SQLAllocHandle on SQL_HANDLE_DBC failed这种情况这时应用与驱动加载的是不同的物理文件，便会导致两套完全同名的函数列表，同时出现在同一个可见域里（UnixODBC的libodbc.so.*的函数导出列表完全一致），产生冲突，无法加载数据库驱动。解决此问题的办法也比较简单，查看LD_LIBRARY_PATH中的第一个unixodbc的lib目录。在其目录下，缺少.2或.1，建立对应的.2或.1的软链接便可。2.3        连接问题2.3.1        服务器不可达典型报错：connect to server failed: no such file or directory此问题可能的原因：·         配置了错误的/不可达的数据库地址，或者端口请检查数据源配置中的Servername及Port配置项，确认网络是通达的。·         服务器listen不正确如果确认Servername及Port配置正确，请根据资料中listen_addresses参数的配置方法，确保数据库listen了合适的网卡及端口，特别是Servername中指定的网卡地址及LVS的虚拟IP地址。修改完记得重启数据库，使listen生效。·         防火墙及网闸、流控设备请确认防火墙设置，将数据库的通信端口添加到可信端口中。如果有网闸、流控设备，请确认一下相关的设置。此问题一般都是第三方商业产品导致，需要咨询服务/产品提供商相关的策略。2.3.2        SSL配置不正确典型报错1：The password-stored method is not supported.解决办法1：请将数据源配置中的的sslmode调整至allow及以上级别，允许使用SSL连接。典型报错2：Server common name "xxxx" does not match host name "xxxxx"  此问题是由于sslmode中使用了全校验(verify-full)，它不仅会校验证书，还会校验证书所在的域名/机器名是否与证书符合，不符合时将报出此问题。解决办法2：重新让CA机构以新的域名/机器名签发证书；或者将SSLMODE调整至verify-ca选项或其以下级别（具体级别见产品资料中的说明）。2.3.3        使用开源驱动连接问题我们的数据库是支持低版本及开源驱动的（V1R7C10及以后），所以可以放心使用。但是偶尔一些从V1R6C10升级上来的数据库，接受开源驱动连接时，会碰到用户认证算法不支持的问题，典型报错如下：authentication method 10 not supported.此问题机理比较复杂，下面详细展开，先说解决办法：·         请使用管理新账号新建一个数据库的用户，并给予其相关的访问权限，使用新用户连接数据库。·         更改当前业务用户的密码，使用新密码连接数据库。解释一下此问题发生的机理：我们的数据库在连接时，是会让客户端将认证信息发过来的。但是发过来的信息不会是明文密码，这是不安全的；客户端发到数据库的认证信息一般是经过加盐后的密码哈希(md5/sha256算法)，迭代次数也非常多。数据库本身也并不存储用户的明文密码，存储的是一个哈希值（所以密码要是丢了，就真的丢了，只能重置不能找回）。数据库在校验这个密码的时候，是比较哈希的，这就涉及到数据库中存储的哈希是使用的什么算法得到的哈希值，常见的是sha256（高斯自研）及MD5（开源）。V1R7C00及以前，数据库中只存储了SHA256的哈希，升级时我们也无法推导用户原有密码，所以升级后仍然只有SHA256的哈希；但是开源客户端只识别MD5的哈希，这就导致数据库无法认证；数据库也只会让客户端以SHA256的哈希来做认证，这时开源就不识别该认证请求，导致报出如上的错误。在创建用户和修改用户密码时，我们的新版本会同时记录两份哈希，所以后续将会同时支持开源及自研的各个版本。 2.3.4        因数据源配置不正确，导致的连接错误典型报错：Data source name not found, and no default driver specified可能原因：1.       数据源名称书写错误（或含有特殊符号）2.       不同的操作系统用户下，数据源可见性不一样；3.       Linux上的数据源配置文件(odbc.ini)位置不正确解决办法：1.       修正数据源名称2.       Windows下，请在当前用户下打开驱动管理器，查看数据源配置是否正确。请注意在64位系统上使用正确的数据源管理器：C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。3.       Linux下使用odbcinst -j 命令，查看当前环境中配置文件的正确路径，输出一般如下：unixODBC 2.3.0DRIVERS............: /usr/local/etc/odbcinst.ini/odbcinst.iniSYSTEM DATA SOURCES: /usr/local/etc/odbcinst.ini/odbc.iniFILE DATA SOURCES..: /usr/local/etc/odbcinst.ini/ODBCDataSourcesUSER DATA SOURCES..: /usr/local/etc/odbc.iniSQLULEN Size.......: 8SQLLEN Size........: 8SQLSETPOSIROW Size.: 8其中USER DATA SOURCES就是用户数据源，优先生效；SYSTEM DATA SOURCES是系统数据源，整个系统可用。请针对这些文件路径，注意：有时用户数据源的配置文件可能是$(HOME)/.odbc.ini2.3.5        通信协议不匹配问题典型报错：unsupported frontend protocol 3.51: server supports 1.0 to 3.0可能原因：使用了新版本的数据库驱动连接老版本的数据库(V1R6C10)；或者使用了我们的驱动，连接到了开源的数据库上。解决办法：1.       请使用老版本的数据库驱动连接该数据库。我们的数据库中，默认低版本客户端可以连接高版本数据库；使用高版本驱动连接低版本客户端，不在规格约束范围内。这个规格也比较好理解：因为用户一般是对数据库集中管理，升级也是有计划的。但是客户端驱动可能嵌入到业务中的每一个角落，有时甚至是已经发布的装备中，升级相对比较困难。2.       如果是开源服务器：我们的数据库驱动不支持开源数据库，无法连接；请使用开源客户端连接。3         其他常见疑问3.1        与开源的区别？1.       增加了安全性，使用了SHA256算法做认证加密；同时调整密钥哈希加密次数2.       提升了批量性能（V1R7C10 2019-4-30及以后版本）3.        3.2        是否可以增加新API？不可以。还是基础知识里那张图，用户引用的API是由驱动管理器提供的，我们提供的API只可供驱动管理器使用；新增API无法穿过中间层为用户提供服务。3.3        是否支持COPY接口？Copy是PG的特有语法及通信协议;而ODBC是微软提出的通用调用接口，所以无此特殊接口。3.4        Linux上的驱动管理器有哪些？驱动管理器在Linux上并不是操作系统的一部分，它也是由其他开源组织开发的。所以并不是只有UnixODBC一种。但是目前使用最广泛的，其实只有UnixODBC，多数据操作系统安装时基本都已经自带了UnixODBC的某个特定版本；除此之外，还有iODBC等，现在已经慢慢退出市场了。3.5        UnixODBC的版本有限制么？有。我们支持2.3.0及以上版本。3.6        UnixODBC的.1与.2的库有什么区别？没有什么区别。这个与UnixODBC的历史有关，历史上有一段时间提供.1，后来做了一次大升级，动态库版本也跟着升级了，变成了.2。但是一大批存量业务受制无法运行，就又添加了.1的支持。.1与.2其实只是UnixODBC的configure配置的一部分，其函数导出，功能完全一致，不必纠结于此。3.7        可以打印日志么？可以。一般建议打印驱动管理器的日志，此日志比较清晰，定位问题比较快。操作办法：·         Windows上：打开驱动管理器，调整到跟踪页面，确定日志文件路径后，点击开始跟踪便可，如图：·         Linux上：打开odbcinst.ini文件（可使用odbcinst -j 来确定文件路径），添加以下章节：[ODBC]Trace=YesTraceFIle=/tmp/odbc.log         重启业务便可。3.8        查询结果集过大，内存吃不消怎么办？打开UseDclareFetch开关，它将会把查询包装成游标操作。对于不支持Cursor with hold的版本慎用。同时由于使用了服务器端的游标，游标的前后滚操作也会反馈给数据库，通信会有所增加，所以性能会有部分下降；可以通过调整Fetch参数来确定每次数据库向客户端反馈的数据量大小，来降低该性能影响。·         Linux下打开UseDeclareFetch的方法：在数据源配置项中添加：UseDeclareFetch=1Fetch=1000·         Windows下打开UseDeclareFetch的方法：         其中的Cache Size选项，就是Fetch的大小。 ##如需完整附件，请留下您的邮箱，我们会及时发送给您

模型训练的时候，注意到有一条日志：UserWarning: Converting sparse IndexedSlices to a dense Tensor of unknown shape. This may consume a large amount of memory.这行日志的意思是：将稀疏的索引切片转换为一个未知形状的稠密Tensor，可能会消耗大量的内存，这就是kernel died的元凶。这个转换动作来源于tf.gather这个算子，如果它的一个入参为稀疏矩阵（稀疏矩阵是线性代数里的数学知识，它表示一个矩阵中有大量值为零，只有少数值非零），它就会默认将这个稀疏矩阵转换成稠密的tensor，会消耗大量内存。稀疏矩阵越大，消耗的内存就越大。因此可以有四个思路去解决这个问题：1、  使用其他算子来替换tf.gather，但是这需要对tf的其他算子很熟悉，需要改大量代码；2、 既然是稀疏矩阵的转换引起了内存的消耗，那就让模型的参数不稀疏就行了。其实加载预训练模型的过程就是将参数值赋值给现有模型，所以加载预训练模型后，稀疏性就降低。但是作业要求不加载预训练模型，因此另一种办法就是对模型进行随机非零值的初始化，这么一种方法进行初始化，也能降低模型参数稀疏性，但也同样需要修改代码；3、  降低模型的复杂度，比如实例分割模型的复杂度和模型输入输出的尺寸有很大的关系，因此可以降低模型输入图片大小，比如将IMAGE_MIN_DIM和IMAGE_MAX_DIM都改成128，IMAGES_PER_GPU改成8，就可以稳定运行了，但对于实际应用场景来说，128尺寸大小的图片很小，容易漏检小物体，应用场景有限；4、  既然tf.gather算子有问题，那么tf官方应该是知道的，也许会在新版本中解决，因此将ipynb的kernel换成tf 1.13，再跑训练，就可以稳定运行了，不会发生kernel died，而且内存的占用比tf 1.8也要更少。 切换kernel，并重新跑通训练的方法如下：依次点击下图中的1、2、3号红框，切换为tf1.13，再屏蔽掉!pip uninstall numpy –y和!pip install numpy==1.15.4，即可重新跑通训练 

按道理导入预训练权重和不导入预训练权重在其他batch_size,img_size保持不变的情况下应该内存和显存消耗都是一致的，但是实际操作发现不导入预训练权重情况下，刚开始训练过一会就会kernel dead，感觉很奇怪，有能帮忙解释一下为什么和怎么解决的吗？

1. 什么是kernel?Python是一种解释型语言，由python解释器来解释一行，并执行一行。Python源文件通常用.py为扩展名，当源文件被解释器加载或者显式地进行字节码编译的时候会被编译成字节码，字节码会被保存为.pyc 或.pyo扩展名的文件，具体是哪个扩展名，取决于解释器的类型和调用解释器的方式。python有五种常用的Python解释器：（1）CPython当从Python官方网站下载并安装好Python2.7后，就直接获得了一个官方版本的解释器：Cpython，这个解释器是用C语言开发的，所以叫CPython，在命名行下运行python，就是启动CPython解释器，CPython是使用最广的Python解释器。在命令行下输入python，看到">>>"，其实就是启动了CPython解释器（2）IPythonIPython是基于CPython之上的一个交互式解释器，也就是说，IPython只是在交互方式上有所增强，但是执行Python代码的功能和CPython是完全一样的，好比很多国产浏览器虽然外观不同，但内核其实是调用了IE。Jupyter  Notebook就是使用IPython解释器。（3）PyPyPyPy是另一个Python解释器，它的目标是执行速度，PyPy采用JIT技术，对Python代码进行动态编译，所以可以显着提高Python代码的执行速度。（4）JythonJython是运行在Java平台上的Python解释器，可以直接把Python代码编译成Java字节码执行。JPython的优势有：只要有 Java 虚拟机，就能运行 Jython拥有访问 Java 包与类库的能力为 Java 开发环境提供了脚本引擎能够很容易的测试 Java 类库提供访问 Java 原生异常处理的能力继承了 JavaBeans 特性和内省能力鼓励 Python 到 Java 的开发（反之亦然）GUI 开发人员可以访问 Java 的 AWT/Swing 库利用了 Java 原生垃圾收集器（CPython 未实现此功能）（5）IronPythonIronPython和Jython类似，只不过IronPython是运行在微软.Net平台上的Python解释器，可以直接把Python代码编译成.Net的字节码。 2. IPython kernel与Jupyter Notebook的关系先看下图了解Jupyter Notebook的架构用户在浏览器里写代码，点击运行后，代码从浏览器发送给Web服务器(tornado)，接着从Web服务器发送消息到Kernel(python)执行代码，在Kernel中执行代码产生的输出/错误会被发送给Web服务器，接着发往给浏览器，用户于是看到输出，这就是Notebook的工作原理。再看一下上图中最右边的部分，可以看到Notebook Server和Kernel之间采用ZeroMQ进行通信，和大多数多进程系统一样，Server和Kernel之间通过心跳机制来监测双方是否还live，整个系统才能保持正常运作。心跳机制的实现方式是定期发一条消息给对方，如果收到对方回复就知道对方还live，如何等了一段时间没收到就认为对方died。如果Server将Kernel判定为died了，真实情况有两种：（1）Kernel这个进程由于执行出错，**作系统杀掉了，确实died了；（2）Kernel还活着，只是通信被阻塞了，Server在有限的时间内没有收到回应，于是Server认为Kernel死了，其实真实情况是kernel并没有死，只是没被检测到还活着。那么，如果你在使用Notebook时经常碰到kernel died，如何解决呢？对应以上两种情况，就有两种解决办法：（1）    降低程序的内存使用需求，并检查代码，避免出现内存溢出的错误，因为碰到这种错误，进程无法自愈，只能由操作系统将其杀掉；（2）    延长心跳机制的等待时间，降低误判进程已死的可能性。

在使用Notebook的时候，经常会有Interrupt kernel、restart kernel的操作，kernel本身也会died。在命令行中输入python，打开的是一个交互式python解释器。那么Notebook里的kernel和常规的交互式python解释器有什么区别？

Kernel RestartingThe kernel appears to have died. It will restart automatically.我的配置：但是并没有加载很多的数据：只是为什么会把我的内存撑爆。求大大帮忙，我该如何改进呢

为什么kernel size=3的时候AI core的mac利用率只有百分之四点多kernel_size=3的时候mac利用率=4.2%，kernel_size=11的时候mac利用率=11.72%，kernel_size=20的时候mac利用率=12%  感觉等于3的时候太低了

kernel_size=3的时候mac利用率=4.2%，kernel_size=11的时候mac利用率=11.72%，kernel_size=20的时候mac利用率=12%  感觉等于3的时候太低了

这是我的notebook配置：GPU: 1*p100 CPU: 8 核 64GiB

如下图所示，右上角Kernel状态ERROR，这是什么原因导致的？是否会影响到Notebook中代码的执行？

我把原来的REDUCTION算子删除了,又重新添加了一个新的,编译也没有报错.能否请华为的朋友帮忙定位一下?谢谢!~

《Atlas 200 软件开发指南 02.pdf》第2章节 ‘安全启动特性’ 里面写到：由于安全启动校验特性，不允许替换表2-1中的7个二进制文件，否则会导致系统无法正常启动。但现在我需要修改Linux kernel 配置选项重新编译出Image，来增加外设驱动支持（不能以ko模块形式编译）。但编译出来的Image是不能启动，这问题怎么解决？另外，还需要修改dtb文件。按介绍说dtb同样也是不能替换的............

#化鲲为鹏，我有话说#ARM（鲲鹏），给您不一样的感觉。eBPF（extended BPF）快速入门（ubuntu版）eBPF是BPF(Berkeley Packet Filter)发展而来的kernel虚拟机，支持在用户态编写kernel代码注入到kernel中运行。具体过程是先用llvm编译得到BPF指令集elf文件，从elf中解析出可注入kernel的部分，用bpf_load_program方法注入。 用户态程序和注入到kernel中的代码通过内核中map通信。为了防止注入的代码导致kernel crash，eBPF会对注入的代码进行检查，拒绝不合格的注入。安装sudo apt-get install bpfcc-tools详解附录：https://www.ibm.com/developerworks/cn/linux/l-lo-eBPF-history/index.htmlhttps://www.lijiaocn.com/%E6%8A%80%E5%B7%A7/2019/02/25/ebpf-introduction-1.html

Terminal中如何进入跟当前实例Notebook kernel一样的python环境？如果您习惯于使用Notebook terminal来运行代码，那么需要切换到和对应Notebook kernel一样的python环境。如果使用单独的AI引擎创建的Notebook实例。运行conda info -e命令查看当前实例下的python虚拟环境。获取对应的虚拟环境之后，运行source activate **命令激活对应的python环境，然后您可以正常使用此python环境。使用结束后，您可以运行source deactivate **命令退出该环境。如果您使用Multi-Engine创建的Notebook实例（即一个Notebook可创建基于多种AI引擎的kernel）。 在teminal的用户目录下，有一个“README”文件，此文件详细说明了如何切换不同的python环境。