Love Sun

2038年问题

前言 在计算机应用上,2038年问题可能会导致某些软件在2038年无法正常工作。所有使用POSIX时间表示时间的程序都将受其影响,因为它们的时间起点是格林尼治时间1970年1月1日0时0分0秒(这个时间名叫 the Unix Epoch),它们用the Unix Epoch经过的秒数(忽略闰秒)来表示时间。这种时间表示法在类Unix(Unix-like)操作系统上是一个标准,并会影响以其C编程语言开发给其他大部份操作系统使用的软件。在大部分的32位操作系统上,此“time_t”数据模式使用一个有符号32位整数(signed int32)存储计算的秒数。依照此“time_t”标准,在此格式能被表示的最后时间是第2147483647秒(代表格林尼治时间2038年1月19日凌晨03:14:07)。下一秒,即格林尼治时间2038年1月19日凌晨03:14:08,由于32位整型溢出,时间将会被“绕回”(wrap around)成一个负数,变成了第 -2147483648 秒(代表格林尼治时间1901年12月13日20:45:52),造成应用程序发生严重的时间错误,而无法运行。 正文 也许大家都已经知道计算机的2000年问题是什么概念,但是什么时候又冒出来一个2038年问题的呢? 用C语言编制的程序不会碰到2000年问题,但是会有2038年问题。这是因为,大多数C语言程序都使用到一个叫做“标准时间库”的程序库,这个时间库用一个标准的4字节也就是32位的形式来储存时间信息。 当初设计的时候,这个4字节的时间格式把1970年1月1日凌晨0时0分0秒(这个时间名叫 the Unix Epoch)作为时间起点,这时的时间值为0。以后所有的时间都是从这个时间开始一秒一秒累积得来的。 比方说如果时间已经累积到了919642718这个数值,就是说这时距离 the Unix Epoch已经过去了919642718秒,换算一下就应该是1999年2月21日16时18分38秒。 这样计算时间的好处在于,把任意两个时间值相减之后,就可以很迅速地得到这两个时间之间相差的秒数,然后你可以利用别的程序把它换算成明白易懂的年月日时分秒的形式。 要是你曾经读过一点儿关于计算机方面的书,你就会知道一个4字节也就是32位的存储空间的最大值是2147483647,请注意!2038年问题的关键也就在这里———当时间一秒一秒地跳完2147483647那惊心动魄的最后一秒后,你猜怎么样? 答案是,它就会转为负数也就是说时间无效。那一刻的准确的时间为2038年1月19日星期二凌晨03:14:07,之后所有用到这种“标准时间库”的C语言程序都会碰到时间计算上的麻烦。 这就是2038年问题。 但是大家也不用太过紧张。2038年问题比千年虫(the Millennium bug)问题解决起来相对要容易一些,只要给那些程序换一个新版本的“标准时间库”就可以了,比如说,改用8字节64位的形式来存储时间。这样做并不怎么费事,因为在C程序中“标准时间库”是相对独立的一个部分,里面的时间表达都有自己的一套时间类型和参数(而在碰到Y2K的那些大型主机中,时间格式大都没有一)。 说到这里,一些冰雪聪明的菜鸟DDMM们应该可以联想到,WindowsNT用的是64位操作平台,它的开始时间是1601年1月1日———但是它每过1个纳秒就跳一下,因此,WindowsNT它会碰到的是2184年问题…… 而在一些用64位来表示时间的平台上,例如DigitalAlpha、SGI、Sparc等等,想要看到它们的时间出错你得等到天荒地老———那大概是2920亿年。到那时,位于猎户座旋臂的太阳,已经是黑矮星或暗黑物质,猎户座旋臂已经被重力波震断,银河系大概则已经变成小型似星体了。 所以,给那些准备攒机的菜鸟DD一个建议,除非您想要把资料流传给下一个宇宙,一台64位的电脑已经足够。 总之,32位的最后时间是2038年1月19日03:14:07,星期二。 64位的最后时间约2900亿年后的292,277,026,596年12月4日15:30:08,星期日。 refer to:http://blog.csdn.net/linyt/article/details/52728910

11.2.0.1.0 exp ORA-01455: converting column overflows integer datatype 错误处理

环境:客户端和服务器端在一台机器,都是11.2.0.1.0 用exp 导出报错。 exp csc/passwd file=csc_.dmp log=csc_.log owner=csc 报错如下: . exporting synonyms . exporting views EXP-00056: ORACLE error 1455 encountered ORA-01455: converting column overflows integer datatype EXP-00000: Export terminated unsuccessfully 解决方法,分析一下需要导出的用户 SQL> exec dbms_stats.gather_schema_stats(ownname => ‘csc’,estimate_percent => 1); 再执行exp,一切ok。 refer to:http://blog.itpub.net/25027760/viewspace-775651/ dbms_stats.gather_schema_stats官方文档

Linux下,多线程程序死循环问题调试

当你的软件在某个时刻停止服务,CPU占用达到100%+,这种问题一个可能的原因是产生了死循环,假设程序某处存在潜在的死循环,并在某种条件下会引发,本文以一个示例来定位出现死循环的位置。 当程序某处存在死循环,通常定位问题及缩小范围的方法是,在可疑的代码处加log,或者注释掉可疑代码,这对于容易重现问题的程序来说还好,但对于“偶尔”才会产生问题程序却很难调试,因为我们很难重现程序故障。本文所述的调试过程正是在这种情况下,假设问题已经出现,我们要求环境保护现场,即出问题的程序还在运行中。 1.我们首先要知道是哪个线程出了问题: 首先查一下出问题进程的pid,例如

然后top命令查看线程信息:

从上面可以看出,出问题线程PID为11073 2.接下来,我们用gdb来attach目标进程 执行:

在gdb中,列出线程状态:

gdb已经列出了各线程正在执行的函数,我们需要更多信息,记住11073对应的行首标号,这是gdb为线程分配的id,这里为2,然后执行切换:

bt一下:

来看一下101行的代码:

现在我们定位到了出问题的代码位置,这里的循环只用来演示的。 最后别忘了detach refer to:http://www.cppblog.com/elva/archive/2010/08/02/121943.html

Linux下定位进程被谁KILL

今天上午有个同事问,自己的进程被莫名其妙的杀死了,想知道是被那个进程误杀了。 第一个想法是用kernel hack系统调用的方式,刚打算翻出hook的代码,想起了貌似audit不就是干这个的吗 #auditctl -a exit,always -S kill #auditctl -l #tail -f /var/log/audit/audit.log 加上这个规则后,再用kill杀死一个进程就可以看到是谁干的了。 type=SYSCALL msg=audit(1446528422.179:18502): arch=c000003e syscall=62 success=yes exit=0 a0=53f a1=8 a2=0 a3=53f items=0 ppid=1427 pid=2613 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=1 comm=”bash” exe=”/usr/bin/bash”…

Linux大文件传输

我们经常需要在机器之间传输文件。比如备份,复制数据等等。这个是很常见,也是很简单的。用scp或者rsync就能很好的完成任务。但是如果文件很大,需要占用一些传输时间的时候,怎样又快又好地完成任务就很重要了。在我的测试用例中,一个最佳的方案比最差的方案,性能提高了10倍。 复制文件 如果我们是复制一个未压缩的文件。这里走如下步骤: 压缩数据 发送到另外一台机器上 数据解压缩 校验正确性 这样做会很有效率,数据压缩后可以更有效的利用带宽 使用ZIP+SCP 我们可以通过ZIP+SCP的组合实现这个功能。

这条命令是将/home/yankay/data经过GZIP压缩,通过ssh传输到yankay01的机器上。 data文件的大小是1.1GB,经过Zip压缩后是183MB,执行上面的命令需要45.6s。平均吞吐量为24.7MB/s 我们会发现Scp也有压缩功能,所以上面的语句可以写成

这样运行效果是相同的,不通之处在于我使用了blowfish算法作为Scp的密匙算法,使用这个算法可以比默认的情况快很多。单单对与scp,使用了blowfish 吞吐量是62MB/s,不使用只有46MB/s。 可是我执行上面一条命令的时候,发现还是需要45s。平均吞吐量还为24MB/s。没有丝毫的提升,可见瓶颈不在网络上。 那瓶颈在哪里呢? 性能分析 我们先定义几个变量 压缩工具的压缩比是 CompressRadio 压缩工具的压缩吞吐是CompressSpeed MB/s 网络传输的吞吐是 NetSpeed MB/s 由于使用了管道,管道的性能取决于管道中最慢的部分的性能,所以整体的性能是: speed=min(NetSpeed/CompressRadio,CompressSpeed) 当压缩吞吐较网络传输慢的时候,压缩是瓶颈;但网络较慢的时候,网络传输/吞吐 是瓶颈。 根据现有的测试数据(纯文本),可以得到表格: 压缩比 吞吐量 千兆网卡(100MB/s)吞吐量 千兆网卡吞吐量,基于ssh(62MB/s) 百兆网卡(10MB/s)吞吐量 ZLIB 35.80%…

Linux下常用的文件传输方式介绍与比较

本文介绍了linux之间传输文件的几种方式,并通过具体实验测试了几种文件传输方式之间的传输速度。这篇文章是我一次作业的实验报告,我经常查看这个文档,所以贴出来方便自己查略。 0. 实验环境以及实验数据 实验环境: 两台装有Ubuntu的电脑,两台电脑位于同一个局域网中,传输速度约4.1MB/s。 实验数据: 使用MySQL的日志文件(ib_logfile0)进行测试,日志文件压缩前1.1G,压缩后159M,具体应用中,压缩比例可能没有这么高,但是不影响我们的讨论。 1. scp scp是secure copy的缩写,scp是linux系统下基于ssh登陆进行安全的远程文件拷贝命令,主要用于linux服务器之间复制文件和目录。scp使用ssh安全协议传输数据,具有和ssh一样的验证机制,从而可以实现安全的远程拷贝文件。 下面介绍SCP三种不同用法的效率。注意:使用SCP前请配制好SSH。 1.1 scp 不使用压缩 将本地文件拷贝到远程服务器:

将远程服务器中的文件拷贝到本地的用法:

经测试,SCP不启用压缩功能的情况下,传输ib_logfile0文件需要4:12s。 1.2 压缩后传输 SCP传输ib_logfile0文件之所以需要那么多时间,是因为它没有对传输的数据进行压缩,可以先 将文件压缩,然后再进行远程拷贝。如下所示:

经测试,先手动压缩,然后再传输,4次测试结果的平均值为00:39s。 1.3 scp启用压缩 相对于第一种方法,第二种方法极大地减少了传输时间,但是需要执行三条语句,较为麻烦。更简单的方法如下所示:

-C选项启用了SSH的压缩功能,通过man ssh可以看到,在-C选项的解释部分有这么一句话:”the compression algorithm is the same used by gzip”。SSH与gzip使用的是同一种压缩算法,即第二种方法与第三种方法几乎一样,但是,第三种方法更为简单方便,所以,推荐使用第三种方法传输数据。…

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt

“Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt” This issue shouldn’t happen in managed code. You can try setting Visual Studio Debugger to bypass this exception: Tools menu…

C/C++获取进程信息

Taking a Snapshot and Viewing Processes The following simple console application obtains a list of running processes. First, the GetProcessList function takes a snapshot of currently executing processes in the system using CreateToolhelp32Snapshot, and then it walks through the list recorded in the snapshot using Process32First and Process32Next. For each process in turn, GetProcessList calls the ListProcessModules function which is described in Traversing the Module List, and the ListProcessThreads function which is described in Traversing the Thread List. A simple error-reporting function, printError, displays the reason for any failures, which usually result from security restrictions.

 

从DataGridView中复制中文到Excel中乱码,怎么解决

DataGridView的KeyUp事件

ListView的KeyUp事件

 

将Linux命令的结果作为下一个命令的参数

1. 符号: 名称:反引号,上分隔符 位置:反引号()这个字符一般在键盘的左上角,数字1的左边,不要将其同单引号(’)混淆 作用:反引号括起来的字符串被shell解释为命令行,在执行时,shell首先执行该命令行,并以它的标准输出结果取代整个反引号(包括两个反引号)部分 举例:

2. $()  效果同 3. 命令:xargs xargs是给命令传递参数的一个过滤器,也是组合多个命令的一个工具。它把一个数据流分割为一些足够小的块,以方便过滤器和命令进行处理。通常情况下,xargs从管道或者stdin中读取数据,但是它也能够从文件的输出中读取数据。xargs的默认命令是echo,这意味着通过管道传递给xargs的输入将会包含换行和空白,不过通过xargs的处理,换行和空白将被空格取代。

管道与xargs的区别: 管道是实现“将前面的标准输出作为后面的标准输入” xargs是实现“将标准输入作为命令的参数” 4. find命令的-exec参数 xargs:通过缓冲方式并以前面命令行的输出作为参数,随后的命令调用该参数 若忽略 xargs 的 options 来看的话, cm1 | xargs cm2 可以单纯看成: cm2 cm1 因此, find …. | xargs rm 也可作 rm…

Page 1 of 3123